Dnia 20 lutego 2018 03:30:10 CET, Ian Stakenvicius <a...@gentoo.org> 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:
>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 p p... )
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
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
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.
Michał Górny (by phone)