1 |
Bernd Steinhauser wrote: |
2 |
|
3 |
> Tiziano Müller schrieb: |
4 |
>> Bernd Steinhauser wrote: |
5 |
>> |
6 |
>>> Tiziano Müller schrieb: |
7 |
>>>> Hi everyone |
8 |
>>>> |
9 |
>>>> I'd like to bring bug #229521 to your attention and see whether we can |
10 |
>>>> come up with a solution for it. |
11 |
>>>> |
12 |
>>>> The problem: |
13 |
>>>> A package "foo" depends on a slotted package "bar" _and_ more than one |
14 |
>>>> slot of "bar" can satisfy this dependency. |
15 |
>>>> |
16 |
>>>> Why this is a problem: |
17 |
>>>> If the dependency looks like one of the following: |
18 |
>>>> * DEPEND=">=cat/bar-2" |
19 |
>>>> * DEPEND="<=cat/bar-3" |
20 |
>>>> * DEPEND="|| ( cat/bar:2 cat/bar:3 ) |
21 |
>>>> then the package manager doesn't know after building "foo" which slot |
22 |
>>>> of "bar" has been used to build "foo". On the other hand might this |
23 |
>>>> information be needed to debug problems with package "foo". |
24 |
>>>> |
25 |
>>>> The problem gets even worse as soon as RDEPEND comes in: |
26 |
>>>> (assuming the same examples from above but with RDEPEND) |
27 |
>>>> * The package manager currently doesn't record which slot has been used |
28 |
>>>> and can't therefore track whether the user will destroy something in |
29 |
>>>> case he uninstalls one of the slots of "bar" |
30 |
>>>> * The package manager can't sanely consider whether an update for a |
31 |
>>>> slot is actually needed |
32 |
>>> There is a section in PMS, that tries to address this. |
33 |
>>> |
34 |
>>> ================= |
35 |
>>> Slot Dependencies |
36 |
>>> A named slot dependency consists of a colon followed by a slot name. A |
37 |
>>> specification with |
38 |
>>> a named slot dependency matches only if the slot of the matched package |
39 |
>>> is equal to the slot |
40 |
>>> specified. If the slot of the package to match cannot be determined |
41 |
>>> (e.g. because it is not a |
42 |
>>> supported EAPI), the match is treated as unsuccessful. |
43 |
>>> An operator slot dependency consists of a colon followed by one of the |
44 |
>>> following operators: |
45 |
>>> * Indicates that any slot value is acceptable. In addition, for runtime |
46 |
>>> dependencies, indicates |
47 |
>>> that the package will not break if the matched package is uninstalled |
48 |
>>> and replaced by a |
49 |
>>> different matching package in a different slot. |
50 |
>>> = Indicates that any slot value is acceptable. In addition, for runtime |
51 |
>>> dependencies, indicates |
52 |
>>> that the package will break unless a matching package with slot equal to |
53 |
>>> the slot of the |
54 |
>>> best installed version at the time the package was installed is |
55 |
>>> available. To implement the equals slot operator, the package manager |
56 |
>>> will need to store the slot of the |
57 |
>>> best installed version of the matching package. The package manager may |
58 |
>>> do this by appending |
59 |
>>> the appropriate slot after the equals sign when saving the package?s |
60 |
>>> dependencies. This syntax |
61 |
>>> is only for package manager use and must not be used by ebuilds. |
62 |
>>> ================= |
63 |
>>> |
64 |
>>> So, if you go with that, the dependency would look like this: |
65 |
>>> DEPEND=">=cat/bar-2:=" |
66 |
>>> |
67 |
>>> That means, that it accepts any slot of versions above version 2, but |
68 |
>>> restricts it to the slot it has been built against, at runtime. |
69 |
>>> The combination of >= and := might look a bit ugly, so maybe it might |
70 |
>>> indeed be useful to specify a way to provide a list of slots. |
71 |
>>> But it would work in most cases. |
72 |
>> |
73 |
>> hmm, this is kdebuild-1... |
74 |
> Indeed, but it is a proposal. |
75 |
> |
76 |
>> I miss two things here: |
77 |
>> a) What happens in case of DEPEND="", RDEPEND=">=cat/bar-2:=" ? Is that |
78 |
>> defined? If yes, what does it mean? If not, what shall be the package |
79 |
>> managers behaviour? |
80 |
> I don't think, that RDEPEND matters here. |
81 |
> If a dep is not in DEPEND, that means, that it doesn't affect the build |
82 |
> process of the package. So in case the dep spec matches more than one |
83 |
> slot, the package should be able to use both without a rebuild. |
84 |
> (Which means, that the package manager can switch the dep.) |
85 |
> If changing the slot would mean, that a rebuild is required, then the |
86 |
> dep affects the package at build time and should be in DEPEND. |
87 |
Oh, my point is much simpler: |
88 |
The kdebuild-1 spec says: "[...] that the package will break unless a |
89 |
matching package with slot equal to the slot of the best installed version |
90 |
at the time the package was installed is available." |
91 |
But: RDEPEND doesn't have to be evaluated before installing the package and |
92 |
DEPEND doesn't contain this package. So, there is no record of such a |
93 |
package. What now? |
94 |
|
95 |
> |
96 |
>> b) It is not said that a package depending on "|| ( cat/bar:2 cat/bar:3 |
97 |
>> )" then really uses cat/bar:3 if available, it might as well use |
98 |
>> cat/bar:2 for one reason or another. It might be clearer if we have slots |
99 |
>> named "stable", "unstable". In such a case a package depending on cat/bar |
100 |
>> might decided to use cat/bar:stable if available instead of |
101 |
>> cat/bar:unstable. So, the spec should either state that the package must |
102 |
>> use the best matching version or we need another way for such cases, like |
103 |
>> a function to explicitly tell the pm which slot has been used. |
104 |
> Not sure if that is a good idea, because you would expect, that those |
105 |
> slot assignments (assuming you mean stable and unstable as list of |
106 |
> slots) get changed if a different slot is now "stable" and that would |
107 |
> break previous assignments. |
108 |
> BTW, you can already name a slot unstable-2 or similar. KDE 4.0 has slot |
109 |
> kde-4, for example. |
110 |
I know :-) |
111 |
|
112 |
> Regarding the || ( cat/bar:2 cat/bar:3 ) construction, if a package |
113 |
> manager chooses one out of the two, it should restrict the package to |
114 |
> this dep at runtime. |
115 |
Hmm, this is the point: What happens if the package chooses cat/bar:2 to |
116 |
link against and the package manager records cat/bar:3 since it assumes |
117 |
this is the better match? Is it it allowed to do the following (it's an |
118 |
example): |
119 |
|
120 |
DEPEND="|| ( sys-libs/db:4.5 sys-libs/db:4.6 )" |
121 |
|
122 |
pkg_setup() { |
123 |
DB_VER="" |
124 |
# both major versions work but prefer 4.5 if available |
125 |
has_version "sys-libs/db:4.5" && DB_VER="4.5" |
126 |
} |
127 |
|
128 |
Questions: |
129 |
a) should DEPEND be valid? |
130 |
b) will has_version evaluate to true? |
131 |
c) how will the pm know that the package chose sys-libs/db:4.5 |
132 |
d) should this be allowed or not? |
133 |
e) if yes, can the package tell the pm about the choice? |
134 |
|
135 |
> Not sure how the several package managers handle this, tbh. |
136 |
|
137 |
>> I think that problem a) is a bit nasty, but it might become better if |
138 |
>> we'd split the dependency variables into DEPEND, RDEPEND, C(OMMON_)DEPEND |
139 |
>> (where the last one would be used for packages needed at compile time and |
140 |
>> runtime). |
141 |
> I would rather vote for labels, which clear the whole dependency thing |
142 |
> up a bit and doesn't splatter them over several vars. |
143 |
> Unfortunately that is not compatible with the current way of specifying |
144 |
> deps. |
145 |
|
146 |
Labels as proposed by kdebuild-1 are only for PDEPEND, right? |
147 |
|
148 |
|
149 |
-- |
150 |
gentoo-dev@l.g.o mailing list |