Re: [gentoo-dev] Portage dependency solving algorithm

[Rich Freeman <rich0@gentoo.org>]

On Sat, Nov 8, 2014 at 2:48 PM, hasufell <hasufell@gentoo.org> wrote:
> 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.

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.

If the user cared which version they had installed they should have to
specify this.  Otherwise the package manager should just assume that
the user doesn't care whether hashable is installed or not - they just
want hashtables installed (or more likely they want something which
needs hashtables installed).

I get that we order || dependencies to hint to the package manager
which dep should be preferred if there is no reason to favor one over
the other.  It shouldn't mean that if you have the second dep
installed that it should try to switch to the first if there are no
conflicts.

In any case, I'm curious as to how you would propose improving such a
dependency?  I definitely see how the syntax could be cleaned up so
that I don't have to poke my eyeballs out, but I don't see what it
would accomplish in terms of dependency resolution (maybe if there was
more use of (sub)slotting and a syntax based on that it might allow
for a different way of searching the dependencies and cut out a few
checks, but I'd have to think about that).

--
Rich