Binary packages and path: dependencies

Thibaut Paumard mlotpot.news at free.fr
Wed Apr 11 07:13:46 PDT 2012


Hi,

Le 11/04/12 15:23, Clemens Lang a écrit :
> 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.

Thanks for your quick answer. Of course this sounds like the obvious
thing to do, I did not know it was allowed or, indeed, possible. Is that
current practice? Would something like this be acceptable or is there a
better alternative:

 depends_lib-append  path:bin/yorick:yorick \
                     port:ffmpeg

 variant devel {
     depends_lib-replace s/port:ffmpeg/port:ffmpeg-devel/
 }

 if { [string match "*(active)*" [exec port installed ffmpeg-devel]] } {
     default_variants +devel
 }

(I tested it, it seems to be working).

> 
>> 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).

Thanks, I did see a few discussions on rev-upgrade, but I did not follow
enough to get what it was about.

Regards, Thibaut.



More information about the macports-dev mailing list