On Wed, Apr 11, 2012 at 03:03:37PM +0200, Thibaut Paumard wrote: > The alternative I can see is to not use a path: dependency in this > case, but to provide two explicit variants (one linking with ffmpeg, > the other with ffmpeg-devel). It would be great if the right variant > could be selected automatically depending on whether or not > ffmpeg-devel is already installed on the system, and I'm not sure how > to do that.
You could put a default_variants statement in a conditional checking whether ffmpeg-devel is installed. > Do you have an opinion on the matter of binary distribution of > packages with path dependencies that can be satisfied by several > ABI-incompatible packages? > > That leads me also to a more generic question, which may be trivial > for you but I can't find the answer on the web: suppose package A > depends on package B. Both are autobuilt at a given point in time. > Later, B is upgraded with an incompatible ABI change. Will A be > automatically rebuilt? If a user has installed A and B, will the two > packages always be upgraded together so they are always in a working > state? Currently, the answer to this question is no. MacPorts 2.1.0 will however contain rev-upgrade that should be able to detect problems like these (as long as the two ABI-incompatible libraries have either different names or different compatibility version numbers). Rev-upgrade will then rebuild the packages from source on the user's system, which should fix this problem. In the future, mpab (the software running the buildbot) should probably extended to run rev-upgrade after upgrading a package, fixing some of those problems. However, this can't fix the problem you are describing unless you deploy the variant solution you just suggested. -- Clemens Lang _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
