1 |
Dnia 2014-08-07, o godz. 15:37:07 |
2 |
Duncan <1i5t5.duncan@×××.net> napisał(a): |
3 |
|
4 |
> Michał Górny posted on Thu, 07 Aug 2014 11:24:43 +0200 as excerpted: |
5 |
> |
6 |
> > With the new policy, the simple form of dependencies: |
7 |
> > |
8 |
> > dev-libs/foo |
9 |
> > |
10 |
> > would be only allowed if dev-libs/foo has only one slot. |
11 |
> > |
12 |
> > If the atom matches more than one slot of a package, one of the |
13 |
> > following forms would need to be used: |
14 |
> > |
15 |
> > 1. dev-libs/bar:* -- if any version of bar is acceptable, |
16 |
> > and you can replace bar:1 with bar:2 without rebuilding, |
17 |
> > |
18 |
> > 2. dev-libs/bar:= -- if any version of bar is acceptable, |
19 |
> > and you need to rebuild bar when changing slots (and subslots), |
20 |
> > |
21 |
> > 3. dev-libs/bar:slot -- if a single slot of bar is acceptable, and you |
22 |
> > can change subslots without rebuilding, |
23 |
> > |
24 |
> > 4. dev-libs/bar:slot= -- if a single slot of bar is acceptable, |
25 |
> > and you need subslot rebuilds, |
26 |
> > |
27 |
> > 5. dev-libs/bar:slot/subslot -- if a single subslot of bar is |
28 |
> > acceptable, useful mostly for binary packages and pass-through virtuals. |
29 |
> |
30 |
> I'm admittedly operating a bit out of my league here so feel free to |
31 |
> ignore this if it's simply noise, but in the interest of a clearer policy |
32 |
> I'll take the risk of being stupid... |
33 |
> |
34 |
> Perhaps this can't happen in practice, but there's an obviously missing |
35 |
> permutation that for completeness (and to avoid questions like this), |
36 |
> probably should have been covered with a notation such as <can't happen>, |
37 |
> or perhaps <can happen but not covered, use the stricter #2 form>: |
38 |
> |
39 |
> 6. dev-libs/bar<what?> -- if any version of bar is acceptable, and you |
40 |
> need to rebuild bar only when changing slots (but not subslots). |
41 |
> |
42 |
> Can it happen? Covered if so? |
43 |
|
44 |
Long story short, PMS doesn't provide a way do this. I can't think of |
45 |
any use case for that, and I think that is one of the reasons no syntax |
46 |
for that was provided. |
47 |
|
48 |
Please note that slot operators := and :* were initially designed to |
49 |
deal with slots alone. You could consider that a coincidence that there |
50 |
were added in the same EAPI as subslots which were invented much later |
51 |
and have a different origin. |
52 |
|
53 |
The slot operators were supposed to help dealing with 'completely' |
54 |
slotted packages, in which slots corresponded to library ABI versions. |
55 |
However, that required some effort to make different versions parallel- |
56 |
-installable. |
57 |
|
58 |
Therefore, subslots were added to allow getting some of the benefits of |
59 |
slotting without all the requirements (like parallel-installability). |
60 |
Subslots are rarely used on their own -- they are usually appended to |
61 |
the slot. Then, the := and :* slot operators simply interpreter 'SLOT' |
62 |
as 'slot/subslot'. |
63 |
|
64 |
> Tho you did switch from dev-libs/foo in the initial statement to |
65 |
> dev-libs/bar in the list of permutations. Normally, I take that to imply |
66 |
> some relationship between foo and bar, thus the need for two labels |
67 |
> instead of reusing the first, but if there is such a relationship here I |
68 |
> don't see it. I am certainly confused but is it because there such a |
69 |
> relationship that I'm simply not seeing (that possibly eliminates my |
70 |
> sixth permutation), or did you "switch horses in mid-stream", as the |
71 |
> saying goes? |
72 |
|
73 |
dev-libs/foo has a single slot. dev-libs/bar has multiple slots. |
74 |
|
75 |
-- |
76 |
Best regards, |
77 |
Michał Górny |