1 |
On 15:25 Fri 17 Dec , Ciaran McCreesh wrote: |
2 |
> How should a dependency like || ( a b c ) be interpreted? |
3 |
> |
4 |
> Traditionally, it's been described as something like: |
5 |
> |
6 |
> * if a matches an installed package, a |
7 |
> * otherwise, if b matches an installed package, b |
8 |
> * otherwise, if c matches an installed package, c |
9 |
> * otherwise, if a is installable, a |
10 |
> * otherwise, if b is installable, b |
11 |
> * otherwise, if c is installable, c |
12 |
> * otherwise, error |
13 |
> |
14 |
> Things get messier when you've got || ( a >b-2.1 ) and b-2.0 is |
15 |
> installed and a is not. Should b be upgraded to 2.1, or should a be |
16 |
> selected? |
17 |
|
18 |
It depends ... see later. |
19 |
|
20 |
> What about if you decide upon a early on, and then later on something |
21 |
> hard-depends upon b? |
22 |
|
23 |
Then you're collapsing the graph too early. =) |
24 |
(speaking as an utter novice) |
25 |
|
26 |
> What about if you've got || ( a[foo] b ) and a[-foo] is installed? |
27 |
|
28 |
See later again.. |
29 |
|
30 |
> As a result of things like this, Portage has had various different sets |
31 |
> of heuristics over time, and Paludis has had a different set. This is |
32 |
> causing problems. Specifically, consider a dependency like the |
33 |
> following, which is present in quite a few ebuilds: |
34 |
> |
35 |
> || ( |
36 |
> <x11-libs/libX11-1.3.99.901[xcb] |
37 |
> >=x11-libs/libX11-1.3.99.901 |
38 |
> ) |
39 |
> |
40 |
> Paludis currently interprets this as "I prefer <1.3.99.901, but will |
41 |
> also accept >=1.3.99.901". In particular, if <1.3.99.901[xcb] is |
42 |
> already installed, libX11 won't be upgraded. Some Portage versions also |
43 |
> do this, and others don't. |
44 |
|
45 |
Why is this a problem that needs to be resolved at the specification |
46 |
level rather than a difference between implementations? If a package |
47 |
manager is making strange choices, |
48 |
|
49 |
> There's one easy fix, which solves this and every other possible |
50 |
> convoluted case (and some of those can be fairly horrible...): require |
51 |
> ebuild developers to always list 'best' things leftmost. So if you're |
52 |
> doing || ( >=a-2 <a-2 ) then you must put the >= dep first (even if the |
53 |
> >= version is masked -- that's guaranteed to work). If the dependency |
54 |
> is rewritten like this then all the ambiguity goes away: |
55 |
|
56 |
I'd thought people already knew that this was typical behavior of an || |
57 |
group (as per the simple example in ebuild(5)), but you've said |
58 |
differently later in this thread. I certainly wouldn't mind documenting |
59 |
that left is best in cases where none are installed, since this has been |
60 |
expected behavior to those of us who do know. |
61 |
|
62 |
However, that doesn't resolve the case where a package is installed but |
63 |
is either too old or has a mismatched USE flag to the dep. It's not |
64 |
clear to me how this proposal would deal with the system-dependent |
65 |
components. |
66 |
|
67 |
I think whether a deep upgrade is requested (or otherwise directly |
68 |
targeting the dependency for possible upgrading) should impact the |
69 |
choice between >= and <. If no upgrade is desired, allow the < dep to be |
70 |
fulfilled; otherwise attempt an upgrade to the newest version and see if |
71 |
it matches. |
72 |
|
73 |
For the mismatched case, I'd attempt to flip the USE unless that would |
74 |
produce a conflict with another package; in that case, pick the leftmost |
75 |
other fulfiller. |
76 |
|
77 |
> || ( |
78 |
> >=x11-libs/libX11-1.3.99.901 |
79 |
> <x11-libs/libX11-1.3.99.901[xcb] |
80 |
> ) |
81 |
> |
82 |
> The other option is that we mandate a particular selection algorithm |
83 |
> for || ( ) dependencies. This is a nuisance, for three reasons: |
84 |
> |
85 |
> * different Portage versions have done different things |
86 |
> |
87 |
> * it prevents the package mangler from doing something clever or |
88 |
> offering additional features |
89 |
> |
90 |
> * every algorithm will do the wrong thing for certain combinations of |
91 |
> dependencies if not given any preference information |
92 |
|
93 |
I think this last point is one of the strongest ones. Humans may need to |
94 |
decide what's best for any specific package's dependencies. |
95 |
|
96 |
> So would anyone be especially opposed to making "best leftmost" an |
97 |
> explicit requirement, enforced by repoman where possible (at least for |
98 |
> the >= / < case)? |
99 |
|
100 |
Not in the entirely ambiguous case, but things are trickier when one of |
101 |
the packages is installed, even in nonmatching version/USE. |
102 |
|
103 |
-- |
104 |
Thanks, |
105 |
Donnie |
106 |
|
107 |
Donnie Berkholz |
108 |
Sr. Developer, Gentoo Linux |
109 |
Blog: http://dberkholz.wordpress.com |