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ł

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to