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

EAPI7 is TL;DR for me right now but I assume that it doesn't specify a
required action for "package broken"?

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to