Re: [gentoo-dev] Portage dependency solving algorithm

[hasufell]

On 11/08/2014 08:32 PM, hasufell wrote:
> 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)
>

To be more specific... it is assumed that hashable-1.2.1.0 is already
installed. Every time the dep solver runs through those packages without
specifying what you want, you will hit the downgrade-problem.

If there was no version of hashable installed at all, then it will also
require user intervention to permit old versions of a package.