Binary packages and path: dependencies

[Clemens Lang]

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