1 |
On 12/17/10 4:25 PM, Ciaran McCreesh wrote: |
2 |
> As a result of things like this, Portage has had various different sets |
3 |
> of heuristics over time, and Paludis has had a different set. |
4 |
|
5 |
Generally it seems fine to have different heuristics (I'll comment on |
6 |
the specific problem below). |
7 |
|
8 |
> Paludis currently interprets this as "I prefer <1.3.99.901, but will |
9 |
> also accept >=1.3.99.901". In particular, if <1.3.99.901[xcb] is |
10 |
> already installed, libX11 won't be upgraded. Some Portage versions also |
11 |
> do this, and others don't. |
12 |
|
13 |
I don't understand why we can't upgrade libX11 in that case. Shouldn't |
14 |
emerge -uDNa world (or its Paludis equivalent) "think" like this: |
15 |
|
16 |
Okay, I have libX11 installed here, and a more recent version is |
17 |
available. The more recent version satisfies this || () dependency, so |
18 |
just update it. |
19 |
|
20 |
> There's one easy fix, which solves this and every other possible |
21 |
> convoluted case (and some of those can be fairly horrible...): require |
22 |
> ebuild developers to always list 'best' things leftmost. |
23 |
|
24 |
Sounds reasonable. |
25 |
|
26 |
> The other option is that we mandate a particular selection algorithm |
27 |
> for || ( ) dependencies. |
28 |
|
29 |
Doesn't that somehow contradict the idea that || () lists equivalent |
30 |
dependencies? Maybe we should fix the heuristics. |
31 |
|
32 |
In this specific case, it seems reasonable to still upgrade libX11, right? |
33 |
|
34 |
> So would anyone be especially opposed to making "best leftmost" an |
35 |
> explicit requirement, enforced by repoman where possible (at least for |
36 |
> the >= / < case)? |
37 |
|
38 |
I don't think that >= / < case is enforceable by repoman (i.e. that we |
39 |
always prefer the more recent version of a package). |
40 |
|
41 |
However, saying that the preferred dependency should be listed first |
42 |
sounds reasonable. |
43 |
|
44 |
Paweł |