1 |
Bernd Steinhauser wrote: |
2 |
|
3 |
> Tiziano Müller schrieb: |
4 |
>> Hi everyone |
5 |
>> |
6 |
>> I'd like to bring bug #229521 to your attention and see whether we can |
7 |
>> come up with a solution for it. |
8 |
>> |
9 |
>> The problem: |
10 |
>> A package "foo" depends on a slotted package "bar" _and_ more than one |
11 |
>> slot of "bar" can satisfy this dependency. |
12 |
>> |
13 |
>> Why this is a problem: |
14 |
>> If the dependency looks like one of the following: |
15 |
>> * DEPEND=">=cat/bar-2" |
16 |
>> * DEPEND="<=cat/bar-3" |
17 |
>> * DEPEND="|| ( cat/bar:2 cat/bar:3 ) |
18 |
>> then the package manager doesn't know after building "foo" which slot of |
19 |
>> "bar" has been used to build "foo". On the other hand might this |
20 |
>> information be needed to debug problems with package "foo". |
21 |
>> |
22 |
>> The problem gets even worse as soon as RDEPEND comes in: |
23 |
>> (assuming the same examples from above but with RDEPEND) |
24 |
>> * The package manager currently doesn't record which slot has been used |
25 |
>> and can't therefore track whether the user will destroy something in |
26 |
>> case he uninstalls one of the slots of "bar" |
27 |
>> * The package manager can't sanely consider whether an update for a slot |
28 |
>> is actually needed |
29 |
> |
30 |
> There is a section in PMS, that tries to address this. |
31 |
> |
32 |
> ================= |
33 |
> Slot Dependencies |
34 |
> A named slot dependency consists of a colon followed by a slot name. A |
35 |
> specification with |
36 |
> a named slot dependency matches only if the slot of the matched package |
37 |
> is equal to the slot |
38 |
> specified. If the slot of the package to match cannot be determined |
39 |
> (e.g. because it is not a |
40 |
> supported EAPI), the match is treated as unsuccessful. |
41 |
> An operator slot dependency consists of a colon followed by one of the |
42 |
> following operators: |
43 |
> * Indicates that any slot value is acceptable. In addition, for runtime |
44 |
> dependencies, indicates |
45 |
> that the package will not break if the matched package is uninstalled |
46 |
> and replaced by a |
47 |
> different matching package in a different slot. |
48 |
> = Indicates that any slot value is acceptable. In addition, for runtime |
49 |
> dependencies, indicates |
50 |
> that the package will break unless a matching package with slot equal to |
51 |
> the slot of the |
52 |
> best installed version at the time the package was installed is available. |
53 |
> To implement the equals slot operator, the package manager will need to |
54 |
> store the slot of the |
55 |
> best installed version of the matching package. The package manager may |
56 |
> do this by appending |
57 |
> the appropriate slot after the equals sign when saving the package?s |
58 |
> dependencies. This syntax |
59 |
> is only for package manager use and must not be used by ebuilds. |
60 |
> ================= |
61 |
> |
62 |
> So, if you go with that, the dependency would look like this: |
63 |
> DEPEND=">=cat/bar-2:=" |
64 |
> |
65 |
> That means, that it accepts any slot of versions above version 2, but |
66 |
> restricts it to the slot it has been built against, at runtime. |
67 |
> The combination of >= and := might look a bit ugly, so maybe it might |
68 |
> indeed be useful to specify a way to provide a list of slots. |
69 |
> But it would work in most cases. |
70 |
|
71 |
hmm, this is kdebuild-1... |
72 |
|
73 |
I miss two things here: |
74 |
a) What happens in case of DEPEND="", RDEPEND=">=cat/bar-2:=" ? Is that |
75 |
defined? If yes, what does it mean? If not, what shall be the package |
76 |
managers behaviour? |
77 |
b) It is not said that a package depending on "|| ( cat/bar:2 cat/bar:3 )" |
78 |
then really uses cat/bar:3 if available, it might as well use cat/bar:2 for |
79 |
one reason or another. It might be clearer if we have slots |
80 |
named "stable", "unstable". In such a case a package depending on cat/bar |
81 |
might decided to use cat/bar:stable if available instead of |
82 |
cat/bar:unstable. So, the spec should either state that the package must |
83 |
use the best matching version or we need another way for such cases, like a |
84 |
function to explicitly tell the pm which slot has been used. |
85 |
|
86 |
I think that problem a) is a bit nasty, but it might become better if we'd |
87 |
split the dependency variables into DEPEND, RDEPEND, C(OMMON_)DEPEND (where |
88 |
the last one would be used for packages needed at compile time and |
89 |
runtime). |
90 |
|
91 |
|
92 |
|
93 |
-- |
94 |
gentoo-dev@l.g.o mailing list |