1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 03/08/14 06:44 PM, Micha³ Górny wrote: |
5 |
> Hello, everyone. |
6 |
> |
7 |
> I would like to hear your opinion on what should be the meaning and |
8 |
> use of '|| ( A:= B:= )' dependencies. [ Snip! ] |
9 |
|
10 |
I mentioned this on irc on Friday; as I understand it the following |
11 |
should occur. |
12 |
|
13 |
Preface: |
14 |
|
15 |
A-1.0's SLOT="0/1" |
16 |
A-2.0's SLOT="0/2" |
17 |
|
18 |
B-1.0's SLOT="4" |
19 |
B-2.0's SLOT="5" |
20 |
|
21 |
|
22 |
When the package is built and merged, it's built against SOMETHING |
23 |
that satisfies ||( A:= B:= ); this means A or B or both are installed. |
24 |
In the Portage implementation the slot of dependencies are recorded |
25 |
in VDB, and so whatever is installed on the system at compile/merge |
26 |
time is what gets recorded to VDB. It's not possible for Portage to |
27 |
know which atom in the ||() list, so VDB needs to match the current state. |
28 |
|
29 |
Case 1 - both A and B are installed - if A-1.0 upgrades to A-2.0, or |
30 |
B-1.0 upgrades to B-2.0, then rebuilds need to be triggered. This |
31 |
should be detectable because A:0/1 and B:4 are recorded in VDB. The |
32 |
fact that they are in a ||() block SHOULD NOT allow the not-upgrading |
33 |
B:4 to keep the dep satisfied if A-1.0 upgrades to A-2.0. Likewise, |
34 |
if either A or B are removed, then the package needs to be rebuilt |
35 |
(once again, it is not known which dep might affect how the package is |
36 |
linked). |
37 |
|
38 |
Case 2 - only A is installed - if A-1.0 upgrades to A-2.0 when B isn't |
39 |
installed at all, this should trigger a rebuild. Hopefully this is |
40 |
what is happening now in all cases. If A-1.0 stays around and B is |
41 |
installed, nothing needs to happen because the package is still linked |
42 |
against A-1.0. However, If A is then removed (say it's dropped from |
43 |
@world and then --depclean'ed), THEN a rebuild needs to be triggered |
44 |
so that a proper (slot) dependency is recorded against B. If A is |
45 |
upgraded after B is installed, then a rebuild needs to be triggered |
46 |
and we end up with Case#1. |
47 |
|
48 |
One thing that is a bit unique with case#2 is that, due to the fact |
49 |
that the subslot is recorded in VDB at merge time, we actually know |
50 |
which atom is satisfying the ||() dep, and so the changes and/or state |
51 |
of the other atom doesn't need to have any affect on this package |
52 |
until the atom that we built against is adjusted (upgraded, removed). |
53 |
|
54 |
|
55 |
|
56 |
|
57 |
> |
58 |
> By the PMS-y definition, any-of dependency can be satisfied by |
59 |
> either branch of it, and the provider can be safely switched at |
60 |
> runtime. That is: |
61 |
> |
62 |
> || ( A B ) |
63 |
> |
64 |
> means that either a or b has to be installed. If you built the |
65 |
> package against A, you can install B, uninstall A and everything is |
66 |
> supposed to work without rebuilding. That doesn't really happen |
67 |
> when linking is involved. |
68 |
|
69 |
|
70 |
Hmm.. that "safely switched at runtime" language technicality might |
71 |
be something we should just honour, since with that in mind " || ( A:= |
72 |
[anything] ) " isn't a valid syntax, if it can only be used for |
73 |
runtime-switchable providers. PMS-wise it may be pertinent to use |
74 |
another operator than || (ie ||= as suggested) to specify a |
75 |
run-or-compile-time-switchable set of atoms. |
76 |
|
77 |
Of course, that means we need to wait for a new EAPI and then rewrite |
78 |
all inappropriate uses of || in the tree, since i believe most ||'s |
79 |
are in fact runtime-or-compiletime-switchable, rather than -just- |
80 |
runtime-switchable. |
81 |
|
82 |
|
83 |
> [ Snip! ] Remaining issues: |
84 |
> |
85 |
> a. behavior of || ( A:= B:= C ) -- should C cause complete |
86 |
> provider switching rebuilds? |
87 |
|
88 |
As per my cases above, no I don't think C should have any effect when |
89 |
it's installed. However, if A or B are removed then the removal |
90 |
should trigger a rebuild. |
91 |
|
92 |
|
93 |
> b. do we need ||= ( A B C ) -- i.e. provider switching rebuilds |
94 |
> without subslot rebuilds? |
95 |
|
96 |
Technically, no I don't think we would need |
97 |
provider-switching-rebuilds without subslot-rebuilds, but that only |
98 |
works if everything in the tree migrates to EAPI5 and implements |
99 |
subslots... Since that's unlikely, though, it might be worth |
100 |
considering.. |
101 |
|
102 |
|
103 |
-----BEGIN PGP SIGNATURE----- |
104 |
Version: GnuPG v2 |
105 |
|
106 |
iF4EAREIAAYFAlPe1sYACgkQ2ugaI38ACPAWiQD/TAilNp7CE5hCaoDikX5ZlSrc |
107 |
GBpx29M6zvmICsS2dqsBALce6lWlMlBFkRjNJ29XykevaRJIjVSHpsExnJiT5c8R |
108 |
=UDaD |
109 |
-----END PGP SIGNATURE----- |