1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 06/09/12 05:01 AM, Fabian Groffen wrote: |
5 |
> Replying to this email since it seems to be the discussion behind |
6 |
> the "sub-slot" feature proposed for EAPI 5. |
7 |
> |
8 |
> On 04-06-2012 23:26:18 +0200, Pacho Ramos wrote: |
9 |
>> This is why I think we should try to push a bit my first |
10 |
>> suggestion for the short term until "the perfect one" is ready |
11 |
>> as, until then, we are having for years a problem that, |
12 |
>> personally, I think it should be handled a bit better. |
13 |
> |
14 |
> After reading this thread, I have seen numerous occasions where has |
15 |
> been asked what this proposal actually solves. Unless I've |
16 |
> accidentially skipped over it, the answer has yet to be given. It |
17 |
> appears to me now sub-slot is a feature that makes it easy to |
18 |
> express a situation that could be expressed today as well, but |
19 |
> requiring more work. As such "syntactic sugar", it seems not well |
20 |
> bounded, allowing possibly for doing things that result in a big |
21 |
> mess (I cannot prove this atm, and there is no specification |
22 |
> afaict.) |
23 |
> |
24 |
|
25 |
#1 - there is both a specification, and an initial implementation, AND |
26 |
a fork of the tree that is kept semi-up-to-date on my dev overlay. So |
27 |
please test away. At present sub-slots have been set on Xorg |
28 |
(automatically rebuilding x11-drivers/* on upgrades), and on perl |
29 |
(automatically rebuilding everything (afaik) that perl-cleaner would |
30 |
normally be needed for). There should be more than enough work done |
31 |
on my portage fork for you to be able to experiment and prove/disprove |
32 |
said mess. |
33 |
|
34 |
#2 - related to your question about what the proposal solves -- in my |
35 |
opinion, the biggest thing the proposal solves is the case where we |
36 |
want the ability to use SLOTs in the tree to manage and track |
37 |
dependency changes (ie, when an API or ABI has changed), but NOT allow |
38 |
multiple versions of a package to be installed at the same time. |
39 |
Further to this, it allows PMs to determine what needs to be rebuilt |
40 |
due to the old (no longer existing) dep being supported prior to said |
41 |
dep actually being removed. |
42 |
|
43 |
|
44 |
|
45 |
> So, I'm looking for a specification what the components in the |
46 |
> sub-slot exactly mean, and what behaviour they trigger. To me, it |
47 |
> seems right now that sub-slot is simply ${SLOT}/${PV}, and some |
48 |
> fancy sub-part matching (up to the '/' actually). It would be nice |
49 |
> to have a sound and clear definition of that the SLOT value means, |
50 |
> and what the sub-slot value means. How can one make it up? Could |
51 |
> one also just start with 1 as sub-slot? Or use names? |
52 |
> (SLOT="2/$(use fnord && echo fnord)"). I have no clue how to use |
53 |
> this correctly, as well as what problems I should have that it |
54 |
> solves. |
55 |
|
56 |
sub-slots is the 'some-identifier' part of ${SLOT}/${some-identifier}. |
57 |
It doesn't have to replate to ${PV} at all, and generally shouldn't. |
58 |
More likely it should relate to the ${major}.${minor} in the main |
59 |
library's SONAME. For non-libtool dependencies some other form of id |
60 |
is used, ie for perl I used the major.minor from $PV. |
61 |
|
62 |
|
63 |
|
64 |
> |
65 |
> To clarify the last bit, could you please explain how the |
66 |
> following situation benefits from sub-slot. |
67 |
> |
68 |
> Consider the packages libfnord, foo and bar. libfnord being a |
69 |
> library, used by foo and bar, which are simple executables. |
70 |
> libfnord has 6 versions (not necessarily all at the same time in |
71 |
> the tree), with ELF soname and library versions: |
72 |
> |
73 |
> libfnord-1 libfnord.so.3 libfnord.so.3.0 libfnord-2 |
74 |
> libfnord.so.5 libfnord.so.5.1 libfnord-2.1 libfnord.so.5 |
75 |
> libfnord.so.5.2 libfnord-2.1-r5 libfnord.so.5 |
76 |
> libfnord.so.5.2 libfnord-3 libfnord.so.5 |
77 |
> libfnord.so.5.8 libfnord-3.5 libfnord.so.5 |
78 |
> libfnord.so.5.12 |
79 |
> |
80 |
> Package foo and bar have the following versions and {,R}DEPEND: |
81 |
> |
82 |
> foo-3.0 >=libfnord-2 bar-1.234b =libfnord-1* |
83 |
> bar-2.4 >=libfnord-3 |
84 |
> |
85 |
> How would the SLOT and {,R}DEPEND values for these ebuilds look |
86 |
> like, what happens when libfnord 2 and 3 are introduced in the |
87 |
> tree, etc. Please show for both EAPI 4, EAPI 4+slot-deps and EAPI |
88 |
> 4+sub-slot. |
89 |
|
90 |
EAPI="4-slot-deps" is new to me; the implementation i've been testing |
91 |
is EAPI="4-slot-abi" which is sub-slots and slot operators. This is |
92 |
the spec that was written and proposed for EAPI=5 and so this is what |
93 |
i'll use to describe the above. |
94 |
|
95 |
First, assuming currently libfnord is SLOT=0, and that there are no |
96 |
ABI/API breakages on libfnord-2 through libfnord-3.5, I would just use |
97 |
the ${major} version from the SONAME for the sub-slot. IE: |
98 |
|
99 |
libfnord-1:SLOT="0/3" |
100 |
libfnord-2:SLOT="0/5" |
101 |
libfnord-2.1:SLOT="0/5" |
102 |
... |
103 |
libfnord-3.5:SLOT="0/5" |
104 |
|
105 |
|
106 |
And then, assuming that foo and bar both link in the usual way, IE |
107 |
they link against libfnord.so.3 instead of just libfnord.so , they |
108 |
both would RDEPEND as follows: |
109 |
|
110 |
RDEPEND="app-cat/libfnord:=" |
111 |
|
112 |
|
113 |
> (numeric indicators added): [1]What if libfnord-2.1 or libfnord-3.5 |
114 |
> would be masked due to some problem not noticed prior to stabling |
115 |
> that makes it useless for many users. [2]bar-2.4 during configure |
116 |
> checks for a new function in libfnord-3.5 and uses it if available, |
117 |
> or uses an alternative code-path instead. [3]libfnord-2.1-r5 fixes |
118 |
> a crash in some function of the library. (Note: this whole |
119 |
> example/question sounds like an ebuild-quiz question that any dev |
120 |
> should be able to answer then.) |
121 |
> |
122 |
> What would be the advantage of sub-slot here, assuming the |
123 |
> versioning of the libraries follows ABI versioning rules defined by |
124 |
> e.g. libtool. |
125 |
|
126 |
[1] No advantage as sub-slots wouldn't relate to this, UNLESS the |
127 |
masking would then remove -all- SLOT="0/5" versions from the tree. In |
128 |
that case, the old SLOT="0/3" provider would be the 'upgrade' path and |
129 |
so 'foo' and 'bar' would be triggered for rebuild (since the lib they |
130 |
were linked to would be disappearing during emerge -uDN) |
131 |
|
132 |
[2] In this case, the new ABI/API offering in libfnord-3.5 would need |
133 |
to be addressed in the SLOT, ie, SLOT="0/5.12". As such when |
134 |
libfnord-3.5 would be upgraded then bar-2.4 (if it was already emerged |
135 |
of course) would be triggered for rebuild. 'foo' would afaik also be |
136 |
triggered for rebuild, though, as (at present) there isn't a way to |
137 |
match partial sub-slots (or sub-sub-slots, as it were) via the slot |
138 |
operators := and :*. |
139 |
|
140 |
[3] No advantage, as linking would be consistent. Sub-slots wouldn't |
141 |
be needed in this case, and afaict updating libfnord-2.1 to |
142 |
libfnord-2.1-r5 wouldn't trigger revdep-rebuild or require any |
143 |
additional mediation anyways. |
144 |
|
145 |
Hope this helps clear things up.. |
146 |
|
147 |
Ian |
148 |
|
149 |
-----BEGIN PGP SIGNATURE----- |
150 |
Version: GnuPG v2.0.19 (GNU/Linux) |
151 |
|
152 |
iF4EAREIAAYFAlBIpGEACgkQ2ugaI38ACPBAAAD/T7kE+KkCJ2IfeHOmP/WYb+CX |
153 |
ofEfsqWXZ2L0aNWDoZIA/0MeHvdH3Yul/SayBbg1Z1Etmiv6vt7f2QqBPArAl/L8 |
154 |
=pLhN |
155 |
-----END PGP SIGNATURE----- |