Re: [gentoo-dev] The meaning of || ( a:= b:= ) dependencies

[Ian Stakenvicius <axs@gentoo.org>]

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