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