On 2018-02-19 07:19 PM, Michael Lienhardt wrote: > > > Il 19/02/2018 20:38, Michał Górny ha scritto: >> W dniu pon, 19.02.2018 o godzinie 21∶32 +0200, użytkownik Mart Raudsepp >> napisał: >>> On Mon, 2018-02-19 at 18:34 +0100, Ulrich Mueller wrote: >>>> It is explained in section 8.2.4: >>>> https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-800008.2.4 >>> >>> Maybe I missed this, but a real world use case example would be nice, >>> maybe someone feels a harder itch to scratch then :) >>> >> >> The original use case was for providers-like thingies, e.g.: >> >> ||= ( ffmpeg:0= libav:0= ) >> >> That said, I'd personally prefer doing that with proper USE_EXPAND >> and REQUIRED_USE enforcing but this has been rejected. >> > > So, if I understand correctly, the ||= group is an "or" that must be > resolved in the same way in the DEPEND and RDEPEND dependencies, right? > > The documentation does not specify how this group interacts between > different ebuilds. > I guess there is no interaction, but just to be sure, let consider the > following corner-case example: > - a package A has RDEPEND=||= ( ffmpeg:0= libav:0= ) while another > package B has DEPEND=ffmpeg > - the solver choose libav to solve the dependency of the first > package and ffmpeg to solve the second, removing ffmpeg afterward > - will package A break? > > Michael Lienhardt
I don't think interaction with other ebuilds is necessarily important, or at least, not any different as what occurs with a package manager decides to do something with the bound atom. Using your example of pkg-A built with libav:0= bound: 1- ffmpeg is merged (lets ignore that ffmpeg blocks libav for now) -- this wouldn't change anything regarding pkg-A as it is currently merged, but if pkg-A is re-emerged for whatever reason then I believe the package manager needs to decide according to the rules to build against ffmpeg. 2- libav is unmerged -- pkg-A is broken. It's likely up to the PM implementation what to do here. In the case of portage, and the libav-unmerge being a soft-blocker, I believe the behaviour would be to trigger a re-emerge of pkg-A which would then through standard dependency resolution decide that it will now depend on ffmpeg. An alternative would be to upgrade the soft-blocker to a hard-blocker since pkg-A is bound to libav:0= and so it can't be resolved automatically. A manual unmerge likely should trigger something about pkg-A too but even in portage's case the user can do that and break dependencies, so it's not obvious to me what would be done. Now, since ffmpeg and libav do block eachother, the switch from one to another would trigger both of these cases which IMO would mean portage would therefore rebuild pkg-A after ffmpeg is emerged (and libav would be unmerged before ffmpeg is merged). And the multi-ebuild interaction that you speak of would simply force ffmpeg as a hard dependency in resolution, triggering the soft-block and therefore the rebuild. EAPI7 is TL;DR for me right now but I assume that it doesn't specify a required action for "package broken"?
signature.asc
Description: OpenPGP digital signature
