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