On 15:25 Fri 17 Dec , Ciaran McCreesh wrote: > 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?
It depends ... see later. > What about if you decide upon a early on, and then later on something > hard-depends upon b? Then you're collapsing the graph too early. =) (speaking as an utter novice) > What about if you've got || ( a[foo] b ) and a[-foo] is installed? See later again.. > 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. Why is this a problem that needs to be resolved at the specification level rather than a difference between implementations? If a package manager is making strange choices, > 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: I'd thought people already knew that this was typical behavior of an || group (as per the simple example in ebuild(5)), but you've said differently later in this thread. I certainly wouldn't mind documenting that left is best in cases where none are installed, since this has been expected behavior to those of us who do know. However, that doesn't resolve the case where a package is installed but is either too old or has a mismatched USE flag to the dep. It's not clear to me how this proposal would deal with the system-dependent components. I think whether a deep upgrade is requested (or otherwise directly targeting the dependency for possible upgrading) should impact the choice between >= and <. If no upgrade is desired, allow the < dep to be fulfilled; otherwise attempt an upgrade to the newest version and see if it matches. For the mismatched case, I'd attempt to flip the USE unless that would produce a conflict with another package; in that case, pick the leftmost other fulfiller. > || ( > >=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 I think this last point is one of the strongest ones. Humans may need to decide what's best for any specific package's dependencies. > So would anyone be especially opposed to making "best leftmost" an > explicit requirement, enforced by repoman where possible (at least for > the >= / < case)? Not in the entirely ambiguous case, but things are trickier when one of the packages is installed, even in nonmatching version/USE. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com
pgpJzD1EkNdBv.pgp
Description: PGP signature
