1 |
How should a dependency like || ( a b c ) be interpreted? |
2 |
|
3 |
Traditionally, it's been described as something like: |
4 |
|
5 |
* if a matches an installed package, a |
6 |
* otherwise, if b matches an installed package, b |
7 |
* otherwise, if c matches an installed package, c |
8 |
* otherwise, if a is installable, a |
9 |
* otherwise, if b is installable, b |
10 |
* otherwise, if c is installable, c |
11 |
* otherwise, error |
12 |
|
13 |
Things get messier when you've got || ( a >b-2.1 ) and b-2.0 is |
14 |
installed and a is not. Should b be upgraded to 2.1, or should a be |
15 |
selected? What about if you decide upon a early on, and then later on |
16 |
something hard-depends upon b? What about if you've got || ( a[foo] |
17 |
b ) and a[-foo] is installed? |
18 |
|
19 |
As a result of things like this, Portage has had various different sets |
20 |
of heuristics over time, and Paludis has had a different set. This is |
21 |
causing problems. Specifically, consider a dependency like the |
22 |
following, which is present in quite a few ebuilds: |
23 |
|
24 |
|| ( |
25 |
<x11-libs/libX11-1.3.99.901[xcb] |
26 |
>=x11-libs/libX11-1.3.99.901 |
27 |
) |
28 |
|
29 |
Paludis currently interprets this as "I prefer <1.3.99.901, but will |
30 |
also accept >=1.3.99.901". In particular, if <1.3.99.901[xcb] is |
31 |
already installed, libX11 won't be upgraded. Some Portage versions also |
32 |
do this, and others don't. |
33 |
|
34 |
There's one easy fix, which solves this and every other possible |
35 |
convoluted case (and some of those can be fairly horrible...): require |
36 |
ebuild developers to always list 'best' things leftmost. So if you're |
37 |
doing || ( >=a-2 <a-2 ) then you must put the >= dep first (even if the |
38 |
>= version is masked -- that's guaranteed to work). If the dependency |
39 |
is rewritten like this then all the ambiguity goes away: |
40 |
|
41 |
|| ( |
42 |
>=x11-libs/libX11-1.3.99.901 |
43 |
<x11-libs/libX11-1.3.99.901[xcb] |
44 |
) |
45 |
|
46 |
The other option is that we mandate a particular selection algorithm |
47 |
for || ( ) dependencies. This is a nuisance, for three reasons: |
48 |
|
49 |
* different Portage versions have done different things |
50 |
|
51 |
* it prevents the package mangler from doing something clever or |
52 |
offering additional features |
53 |
|
54 |
* every algorithm will do the wrong thing for certain combinations of |
55 |
dependencies if not given any preference information |
56 |
|
57 |
So would anyone be especially opposed to making "best leftmost" an |
58 |
explicit requirement, enforced by repoman where possible (at least for |
59 |
the >= / < case)? |
60 |
|
61 |
-- |
62 |
Ciaran McCreesh |