-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/08/14 06:44 PM, Michał Górny wrote: > Hello, everyone. > > I would like to hear your opinion on what should be the meaning and > use of '|| ( A:= B:= )' dependencies. [ Snip! ]
I mentioned this on irc on Friday; as I understand it the following should occur. Preface: A-1.0's SLOT="0/1" A-2.0's SLOT="0/2" B-1.0's SLOT="4" B-2.0's SLOT="5" When the package is built and merged, it's built against SOMETHING that satisfies ||( A:= B:= ); this means A or B or both are installed. In the Portage implementation the slot of dependencies are recorded in VDB, and so whatever is installed on the system at compile/merge time is what gets recorded to VDB. It's not possible for Portage to know which atom in the ||() list, so VDB needs to match the current state. Case 1 - both A and B are installed - if A-1.0 upgrades to A-2.0, or B-1.0 upgrades to B-2.0, then rebuilds need to be triggered. This should be detectable because A:0/1 and B:4 are recorded in VDB. The fact that they are in a ||() block SHOULD NOT allow the not-upgrading B:4 to keep the dep satisfied if A-1.0 upgrades to A-2.0. Likewise, if either A or B are removed, then the package needs to be rebuilt (once again, it is not known which dep might affect how the package is linked). Case 2 - only A is installed - if A-1.0 upgrades to A-2.0 when B isn't installed at all, this should trigger a rebuild. Hopefully this is what is happening now in all cases. If A-1.0 stays around and B is installed, nothing needs to happen because the package is still linked against A-1.0. However, If A is then removed (say it's dropped from @world and then --depclean'ed), THEN a rebuild needs to be triggered so that a proper (slot) dependency is recorded against B. If A is upgraded after B is installed, then a rebuild needs to be triggered and we end up with Case#1. One thing that is a bit unique with case#2 is that, due to the fact that the subslot is recorded in VDB at merge time, we actually know which atom is satisfying the ||() dep, and so the changes and/or state of the other atom doesn't need to have any affect on this package until the atom that we built against is adjusted (upgraded, removed). > > By the PMS-y definition, any-of dependency can be satisfied by > either branch of it, and the provider can be safely switched at > runtime. That is: > > || ( A B ) > > means that either a or b has to be installed. If you built the > package against A, you can install B, uninstall A and everything is > supposed to work without rebuilding. That doesn't really happen > when linking is involved. Hmm.. that "safely switched at runtime" language technicality might be something we should just honour, since with that in mind " || ( A:= [anything] ) " isn't a valid syntax, if it can only be used for runtime-switchable providers. PMS-wise it may be pertinent to use another operator than || (ie ||= as suggested) to specify a run-or-compile-time-switchable set of atoms. Of course, that means we need to wait for a new EAPI and then rewrite all inappropriate uses of || in the tree, since i believe most ||'s are in fact runtime-or-compiletime-switchable, rather than -just- runtime-switchable. > [ Snip! ] Remaining issues: > > a. behavior of || ( A:= B:= C ) -- should C cause complete > provider switching rebuilds? As per my cases above, no I don't think C should have any effect when it's installed. However, if A or B are removed then the removal should trigger a rebuild. > b. do we need ||= ( A B C ) -- i.e. provider switching rebuilds > without subslot rebuilds? Technically, no I don't think we would need provider-switching-rebuilds without subslot-rebuilds, but that only works if everything in the tree migrates to EAPI5 and implements subslots... Since that's unlikely, though, it might be worth considering.. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlPe1sYACgkQ2ugaI38ACPAWiQD/TAilNp7CE5hCaoDikX5ZlSrc GBpx29M6zvmICsS2dqsBALce6lWlMlBFkRjNJ29XykevaRJIjVSHpsExnJiT5c8R =UDaD -----END PGP SIGNATURE-----
