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
signature.asc
Description: PGP signature