How should a dependency like || ( a b c ) be interpreted?

Traditionally, it's been described as something like:

* if a matches an installed package, a
* otherwise, if b matches an installed package, b
* otherwise, if c matches an installed package, c
* otherwise, if a is installable, a
* otherwise, if b is installable, b
* otherwise, if c is installable, c
* otherwise, error

Things get messier when you've got || ( a >b-2.1 ) and b-2.0 is
installed and a is not. Should b be upgraded to 2.1, or should a be
selected? What about if you decide upon a early on, and then later on
something hard-depends upon b? What about if you've got || ( a[foo]
b ) and a[-foo] is installed?

As a result of things like this, Portage has had various different sets
of heuristics over time, and Paludis has had a different set. This is
causing problems. Specifically, consider a dependency like the
following, which is present in quite a few ebuilds:

    || ( 
        <x11-libs/libX11-1.3.99.901[xcb]
        >=x11-libs/libX11-1.3.99.901
    )

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.

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. So if you're
doing || ( >=a-2 <a-2 ) then you must put the >= dep first (even if the
>= version is masked -- that's guaranteed to work). If the dependency
is rewritten like this then all the ambiguity goes away:

    || ( 
        >=x11-libs/libX11-1.3.99.901
        <x11-libs/libX11-1.3.99.901[xcb]
    )

The other option is that we mandate a particular selection algorithm
for || ( ) dependencies. This is a nuisance, for three reasons:

* different Portage versions have done different things

* it prevents the package mangler from doing something clever or
  offering additional features

* every algorithm will do the wrong thing for certain combinations of
  dependencies if not given any preference information

So would anyone be especially opposed to making "best leftmost" an
explicit requirement, enforced by repoman where possible (at least for
the >= / < case)?

-- 
Ciaran McCreesh