Re: [gentoo-dev] Portage dependency solving algorithm

[hasufell]

On 11/08/2014 08:01 PM, Matthias Dahl wrote:
> Hello Ciaran...
>
> On 08/11/14 19:26, Ciaran McCreesh wrote:
>
>> No. It would make sense to introduce a cultural change, where
>> developers stop writing dependencies that seem to work with some
>> particular version of Portage if you don't look very closely, and start
>> writing good dependencies.
>
> Sorry to chime in like that but if you don't mind, I'd like to ask for a
> real-life example for badly declared dependencies with a few words why
> those are bad and how to make them actually better?
>

from dev-haskell/hashtables (note "hashtables" != "hashable"):
|| ( ( >=dev-haskell/hashable-1.1:=[profile?]
       <dev-haskell/hashable-1.2:=[profile?] )
     ( >=dev-haskell/hashable-1.2.1:=[profile?]
       <dev-haskell/hashable-1.3:=[profile?] )
   )

Latest stable version of dev-haskell/hashable is 1.2.1.0.
On a stable system (arch) the paludis dep-solver will try to match the
first group first and realize that there is also a stable version
1.1.2.5 that matches that group. At that point there is a correct
solution, but since that involves downgrading a package, it will require
user-intervention, because it may not be what the user wants.
(this is the easy scenario... if downgrading causes blockers, you get
much more interesting output)

If you want "user friendliness", then such dependencies would require
that the dep-solver tries very very hard to find a solution which *may*
be what the user wants... or not. I don't think that's what "||" were
designed for (if there was a design behind it).

Ofc there is a solution to that, e.g. by using
--favour-matching '>=dev-haskell/hashable-1.2.1'
which explicitly tells the dep-solver what the user wants.


perl virtuals can be similarly interesting.