Re: [gentoo-dev] Portage dependency solving algorithm

[Zac Medico <zmedico@gentoo.org>]

On 11/08/2014 02:05 PM, hasufell wrote:
> On 11/08/2014 10:52 PM, Jauhien Piatlicki wrote:
>> 08.11.14 22:47, hasufell написав(ла):
>>> On 11/08/2014 10:30 PM, Rich Freeman wrote:
>>>> On Sat, Nov 8, 2014 at 2:48 PM, hasufell <hasufell@gentoo.org> wrote:
>>>>> On 11/08/2014 08:32 PM, hasufell wrote:
>>>>>>> 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.
>>>>
>>>> I'm missing the problem.  The package requires one of two ranges of
>>>> hashable versions.  One of them is already installed.  The dependency
>>>> is satisfied.
>>>>
>>>
>>> The one that is installed (1.2.1.0) is *excluded* by the first group,
>>> but there is a valid version that fits instead (1.1.2.5).
>>>
>>> That's the point where the assumptions start about what the depstring
>>> means and what the user wants.
>>>
>>
>> So the problem is only with intervals? First of all, maintainer would specify higher interval first here and it would solve a problem with possible downgrading.
> 
> I have a feeling that this is an assumption as well. PMS just says this
> is an 'any-of' group. There is not a single word about the processing
> order of these specs or which one to prefer, in which case some is
> better than the other and so on.

I think the two obvious algorithms are:

A) If the user's resolver parameters request maximum upgrades, then the
resolver should choose the choice that results the most upgrades.

B) If the user's resolver parameters request minimum change, then the
resolver should choose the choice which results in keeping the most
installed packages in place.

For the dev-haskell/hashtables scenario, the choice on the right wins
regardless of whether you're using algorithm A or algorithm B.
-- 
Thanks,
Zac