Re: [gentoo-dev] EAPI 7 in Portage needs YOU!

[Michał Górny]

Dnia 20 lutego 2018 03:30:10 CET, Ian Stakenvicius <axs@g.o> napisał(a):
>On 2018-02-19 12:34 PM, Ulrich Mueller wrote:
>>>>>>> On Mon, 19 Feb 2018, Michael Lienhardt wrote:
>>
>>>> 2. ||= (binding any-of) dep groups.
>>
>>> I don't understand what this group means, and the PMS-7 is
>>> unclear as well: "binding-any-of A binding-any-of group, which
>>> has the same format as the any-of group, but begins with the
>>> string ||= instead." Is it a "or", like the "any-of" group, but
>>> with a different behavior at compiling/linking time?
>>
>> It is explained in section 8.2.4:
>> https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-800008.2.4
>>
>> Ulrich
>>
>
>
>Could we get some clarification/confirmation on this language?:
>
>
>> In addition, for runtime dependencies, indicates that the package
>> will break unless a matching package corresponding to the first
>> immediate child element (in order of listing) installed as a
>> build-time (DEPEND) dependency is available
>
>
>...if I am reading this right, this means that the list of atoms is
>iterated through first->last, and as soon as one is found to be
>available at build-time, it chosen as the one that this package is
>bound to and after that the package will be considered broken if it
>doesn't exist/is later removed?

Yes. Let me expand on that. Given a dep:

  ||= ( p[0] p[1] p[2]... )

p[i] with lower i has higher priority.

Implementation-wise, at the very minimum:

1. PM needs to ensure that at least one of p[i] is installed (doesn't matter which one).

2. PM needs to seek through p[i] at build time and record the p[i] with lowest i that was satisfied somehow (with explicit indication how it was obtained).

3. PM needs to treat this p[i] as unconditional (but weak-ish) dep, i.e. 'emerge --depclean' must not remove it even if p[j], j!=i is present.

4. Also, it needs to handle missing all p[i] in a non-crashing fashion, i.e. without requiring user to fix it manually.

However, if we want it to do more then locking deps forever, we should also consider the following (with i!=j):

1. If p[i] is locked, and p[j] is requested and blocking p[i], package should be rebuilt after installing p[j] and removing p[i]. 

2. If p[i] is locked, and p[j] gets installed where j<i (no blockers), PM may want to rebuild pkg to unlock p[i] (this should probably be controlled by option).

3. If p[i] is locked, and p[j] is installed where j>i (no blockers), PM should provide some way of uninstalling p[i] (and rebuilding pkg afterwards). My idea was to allow blocker syntax for emerge, i.e. "emerge -1v !dev-libs/foo " which would uninstall it like a blocker and rebuild all pkgs with weak deps.

-- 
Best regards,
Michał Górny (by phone)