1 |
On 06-09-2012 09:25:53 -0400, Ian Stakenvicius wrote: |
2 |
> #1 - there is both a specification, and an initial implementation, AND |
3 |
> a fork of the tree that is kept semi-up-to-date on my dev overlay. |
4 |
|
5 |
I was interested in a (formal) specification, not a proof of concept. |
6 |
|
7 |
> #2 - related to your question about what the proposal solves -- in my |
8 |
> opinion, the biggest thing the proposal solves is the case where we |
9 |
> want the ability to use SLOTs in the tree to manage and track |
10 |
> dependency changes (ie, when an API or ABI has changed), but NOT allow |
11 |
> multiple versions of a package to be installed at the same time. |
12 |
> Further to this, it allows PMs to determine what needs to be rebuilt |
13 |
> due to the old (no longer existing) dep being supported prior to said |
14 |
> dep actually being removed. |
15 |
|
16 |
... |
17 |
|
18 |
> sub-slots is the 'some-identifier' part of ${SLOT}/${some-identifier}. |
19 |
> It doesn't have to replate to ${PV} at all, and generally shouldn't. |
20 |
> More likely it should relate to the ${major}.${minor} in the main |
21 |
> library's SONAME. For non-libtool dependencies some other form of id |
22 |
> is used, ie for perl I used the major.minor from $PV. |
23 |
|
24 |
> EAPI="4-slot-deps" is new to me; the implementation i've been testing |
25 |
|
26 |
You refer to it lateron, so it seems to me you're unaware your sub-slots |
27 |
and slot-deps are made as one commit [1]. |
28 |
|
29 |
> is EAPI="4-slot-abi" which is sub-slots and slot operators. This is |
30 |
> the spec that was written and proposed for EAPI=5 and so this is what |
31 |
> i'll use to describe the above. |
32 |
|
33 |
both are proposed for EAPI=5 [2] |
34 |
|
35 |
> First, assuming currently libfnord is SLOT=0, and that there are no |
36 |
> ABI/API breakages on libfnord-2 through libfnord-3.5, I would just use |
37 |
> the ${major} version from the SONAME for the sub-slot. IE: |
38 |
> |
39 |
> libfnord-1:SLOT="0/3" |
40 |
> libfnord-2:SLOT="0/5" |
41 |
> libfnord-2.1:SLOT="0/5" |
42 |
> ... |
43 |
> libfnord-3.5:SLOT="0/5" |
44 |
> |
45 |
> And then, assuming that foo and bar both link in the usual way, IE |
46 |
> they link against libfnord.so.3 instead of just libfnord.so , they |
47 |
|
48 |
SONAME indeed refers to the versioned lib, although linking is of course |
49 |
done against libfnord.so (-lfnord). |
50 |
|
51 |
> both would RDEPEND as follows: |
52 |
> |
53 |
> RDEPEND="app-cat/libfnord:=" |
54 |
|
55 |
This is "Slot operator dependencies" syntax. |
56 |
|
57 |
> > (numeric indicators added): [1]What if libfnord-2.1 or libfnord-3.5 |
58 |
> > would be masked due to some problem not noticed prior to stabling |
59 |
> > that makes it useless for many users. [2]bar-2.4 during configure |
60 |
> > checks for a new function in libfnord-3.5 and uses it if available, |
61 |
> > or uses an alternative code-path instead. [3]libfnord-2.1-r5 fixes |
62 |
> > a crash in some function of the library. (Note: this whole |
63 |
> > example/question sounds like an ebuild-quiz question that any dev |
64 |
> > should be able to answer then.) |
65 |
> > |
66 |
> > What would be the advantage of sub-slot here, assuming the |
67 |
> > versioning of the libraries follows ABI versioning rules defined by |
68 |
> > e.g. libtool. |
69 |
> |
70 |
> [1] No advantage as sub-slots wouldn't relate to this, UNLESS the |
71 |
> masking would then remove -all- SLOT="0/5" versions from the tree. In |
72 |
> that case, the old SLOT="0/3" provider would be the 'upgrade' path and |
73 |
> so 'foo' and 'bar' would be triggered for rebuild (since the lib they |
74 |
> were linked to would be disappearing during emerge -uDN) |
75 |
|
76 |
So your example SLOTs are wrong, and should have included the minor |
77 |
(always!?!) since downgrading a lib that goes back to an older minor |
78 |
means functions no longer exist, thus a consumer can potentially break. |
79 |
|
80 |
> [2] In this case, the new ABI/API offering in libfnord-3.5 would need |
81 |
> to be addressed in the SLOT, ie, SLOT="0/5.12". As such when |
82 |
> libfnord-3.5 would be upgraded then bar-2.4 (if it was already emerged |
83 |
> of course) would be triggered for rebuild. 'foo' would afaik also be |
84 |
> triggered for rebuild, though, as (at present) there isn't a way to |
85 |
> match partial sub-slots (or sub-sub-slots, as it were) via the slot |
86 |
> operators := and :*. |
87 |
|
88 |
So you basically say: this is slot-dep, you store that bar-2.4 uses |
89 |
libfnord-2.1. |
90 |
|
91 |
> [3] No advantage, as linking would be consistent. Sub-slots wouldn't |
92 |
> be needed in this case, and afaict updating libfnord-2.1 to |
93 |
> libfnord-2.1-r5 wouldn't trigger revdep-rebuild or require any |
94 |
> additional mediation anyways. |
95 |
|
96 |
Yes. |
97 |
|
98 |
> Hope this helps clear things up.. |
99 |
|
100 |
I think I understand why ciaramn suggested the use of / iso SUB_SLOT (or |
101 |
something like that) here. |
102 |
|
103 |
Could you give an example where implicit ${PV} as sub-slot would not do |
104 |
what you need? |
105 |
|
106 |
Do you allow sub-slot to depend on e.g. USE-flags in use? Suppose |
107 |
libfnord has a USE-flag cow that adds special cow interfaces to the |
108 |
ABI/API. Would SLOT="X/${PV}$(use cow && echo -- -cow)" work? |
109 |
(I think SLOT is supposed to be metadata-static, but does the sub-slot |
110 |
part count to that?) |
111 |
|
112 |
|
113 |
[1] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01 |
114 |
[2] http://wiki.gentoo.org/wiki/EAPI_5_tentative_features |
115 |
|
116 |
-- |
117 |
Fabian Groffen |
118 |
Gentoo on a different level |