Created attachment 438962 [details, diff] Equals slot operator: Clarify/specify when to store the slot/sub-slot part. Will follow two patches trying to clarify this. First one clarifies when to store slot/sub-slot pair for packages in dependencies: It shall only be done for packages used to match a dependency. I thought this was obvious and implicit, but reading [1] I now have doubts. portage & paludis seem to get this right, pkgcore seems to crash/fail when it encounters a := dep that is not installed. [1] https://blogs.gentoo.org/mgorny/2016/06/21/dependency-pitfalls-regarding-slots-slot-ops-and-any-of-deps/ PS: I hope you don't mind the broken line-wrapping I used to make the diff more readable.
Created attachment 438964 [details, diff] Equals slot operator: Clarify/specify how to store the slot/sub-slot part when saving packages dependencies This one is probably more controversial. Let's see what people think about it, but I'd like to ask council for approval/rejection of such a change. It changes the suggestion of adding the slot/sub-slot part in place by adding a new dependency where it has added the slot/sub-slot part. For standard dependencies, like "a:=", this could be stored as "a:= a:0/0=", but since "a:0/0=" is a subset of "a:=" it is equivalent to "a:0/0=": It makes no difference. For "|| ( a:= b:= )" dependencies (and their variants), per the first patch, PM is free to chose whichever of 'a' or 'b' in order to match the dependency. Let's say it chose 'a'. The dependency will be stored as: "|| ( a:= b:= ) a:0/0=", binding the package to 'a'. This is not equivalent to "|| ( a:0/0 b:= )": bug 489458 comment 13 has a good & simple example as to why. For exclusive-|| deps (be it because they are mutual blocker or for more indirect reasons), this will always work as expected: There will always be only one package matching the dependency and the package will be bound to the provider it has been built against. Please note that this is the vast majority of the use cases seen as blockers of bug #586238. For non-exclusive-|| deps (when, in the above, a and b can both be installed), PM is indeed free to chose whichever provider of the || it binds the package to. Therefore, the behavior is unspecified, bug #489458 being an attempt at specifying it. Such usage should probably be discouraged/banned in devmanual, but if we think about it, it is already somewhat banned: Suppose we have a '|| ( a b )' dep where a ':=' dep would make sense on 'b'. This might mean that such a package should be rebuilt if e.g. 'b' was installed when the package was built and 'b' is removed, or might also mean that if 'a' is installed then it binds to 'a' and does not use 'b' at all. PM has no way to know this, but let's assume it is the former: package has a '|| ( a b )' dependency, is built with both 'a' and 'b' installed, and should be rebuilt if 'b' is removed. If nothing else pulls in 'b', PM is free to depclean 'b', and thus, with the above assumptions, leaving our package in a broken state: This is nothing else than a kind of automagic dependency. As an added bonus, this avoids introducing useflags that are not really useflags in the sense that they do not change any feature of the package but only the dependencies they pull. I believe such """useflags""" are only cluttering ebuilds, such as the 'libressl' useflag: The vast majority the 'libressl' useflags are used, as only purpose, to pull libressl instead of openssl. In more complex cases, this could even avoid fiascos such as bug #569818. PS: Sorry again for broken line-wrapping in the patch.
(In reply to Alexis Ballier from comment #1) > Created attachment 438964 [details, diff] [details, diff] > Equals slot operator: Clarify/specify how to store the slot/sub-slot part > when saving packages dependencies > > This one is probably more controversial. Let's see what people think about > it, but I'd like to ask council for approval/rejection of such a change. > > > It changes the suggestion of adding the slot/sub-slot part in place by > adding a new dependency where it has added the slot/sub-slot part. It doesn't. If you really want to do this, state it plainly. 'Inserting' vs 'adding' is completely non-obvious for a person that doesn't see the diff, and I'm pretty sure many people will interpret it as 'add here' rather than 'add somewhere else'. > For "|| ( a:= b:= )" dependencies (and their variants), per the first patch, > PM is free to chose whichever of 'a' or 'b' in order to match the > dependency. Let's say it chose 'a'. The dependency will be stored as: "|| ( > a:= b:= ) a:0/0=", binding the package to 'a'. This is not equivalent to "|| > ( a:0/0 b:= )": bug 489458 comment 13 has a good & simple example as to why. ...which means you can't install B, ever. Because you have a package that strictly requires A in non-conditional block. You have to uninstall all packages using those deps to actually be able to install B.
(In reply to Michał Górny from comment #2) > (In reply to Alexis Ballier from comment #1) > > Created attachment 438964 [details, diff] [details, diff] [details, diff] > > Equals slot operator: Clarify/specify how to store the slot/sub-slot part > > when saving packages dependencies > > > > This one is probably more controversial. Let's see what people think about > > it, but I'd like to ask council for approval/rejection of such a change. > > > > > > It changes the suggestion of adding the slot/sub-slot part in place by > > adding a new dependency where it has added the slot/sub-slot part. > > It doesn't. If you really want to do this, state it plainly. 'Inserting' vs > 'adding' is completely non-obvious for a person that doesn't see the diff, > and I'm pretty sure many people will interpret it as 'add here' rather than > 'add somewhere else'. Note that 'inserting' in current PMS applies to the slot/sub-slot part while 'adding' here applies to a complete dependency (cat/pkg:slot/sub-slot). Considering PMS 8.2: "The following elements are recognised in at least one class of specification. All elements must be surrounded on both sides by whitespace, except at the start and end of the string.", I believe "adding" is clear and simply means "adding an element to that set". Feel free to propose a more straightforward wording though. Note also that the idea is to specify the bare minimum of requirements in order to remove room for interpretation that could allow having cases I think we all agree do not make sense (and ideally only those, which I think is the case here). > > For "|| ( a:= b:= )" dependencies (and their variants), per the first patch, > > PM is free to chose whichever of 'a' or 'b' in order to match the > > dependency. Let's say it chose 'a'. The dependency will be stored as: "|| ( > > a:= b:= ) a:0/0=", binding the package to 'a'. This is not equivalent to "|| > > ( a:0/0 b:= )": bug 489458 comment 13 has a good & simple example as to why. > > ...which means you can't install B, ever. Because you have a package that > strictly requires A in non-conditional block. You have to uninstall all > packages using those deps to actually be able to install B. Definitely not more than 'a:0/0=' prohibits PM from upgrading 'a' to 'a:0/1': PM is free to trigger a rebuild and use the ebuild in those cases. We also already happen to have a working implementation [1]. It is a completely different debate, but if it were up to me, I wouldn't even change package's dependencies but rather use a separate list for 'a:0/0=' deps that would only be considered as rebuild-triggers, meaning it doesn't leave room for choice to the PM: if slot/sub-slot changes, pull ebuild into the depgraph for a rebuild; instead of, as it is now, leaving the choice to upgrade and rebuild or not to the PM. Believe me, when dealing with NP-hard problems, the less choice, the better :) However, this debate is void since Zac got it to work even with this added complexity. [1] https://archives.gentoo.org/gentoo-dev/message/7a64ef56c01ae75a4a73707eeebac5d6
This has stalled. I would like to request council for a vote and close the issue. I am, again, running into a case where this would make sense: dev-lang/ocaml has split the 'num' package in its latest version (4.06). Whenever dev-lang/ocaml or the (not yet added because of this bug) split dev-ml/num is updated (new version), rev deps need to be rebuilt. A proper dep for this would be: '|| ( dev-ml/num:= <dev-lang/ocaml-4.06.0_alpha:= )' As of today, the only way to make this happen is to remove the := dep, letting packages break at every update and users to figure out what needs to be rebuilt. The other option is to revbump all packages requiring 'dev-ml/num' and make the dep mandatory. This would work but has a big drawback of requiring to coordinate dozens of packages visibility. All those options are rather suboptimal considering the proper fix has been sitting attached to this bug for 1+year.
The Council has voted on this on 2017-11-12 meeting and with 5 'no' votes and 2 abstentions rejected the proposed patches. The relevant log [1] part starts at 21:14 (CET). [1]:https://projects.gentoo.org/council/meeting-logs/20171112.txt
For the record, ||= has been accepted into EAPI 7 as a proper solution to this problem.
