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: >> 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)
