Regarding my final year thesis

classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Jauhien Piatlicki-2
07.11.14 21:44, hasufell написав(ла):
> On 11/07/2014 08:56 PM, Jauhien Piatlicki wrote:
>
> Every time people compare portage to paludis I read stuff like "but
> paludis is slower". That is incomplete information to put it diplomatic.
>
> Do you really care so much about speed that you don't mind wrong results?
>

My original question was about Portage being too slow. And Paludis came out just as an alternative.

And I would like to see a detailed discussion about what's wrong from the point of view of correctness with:

1. PMS

2. ebuilds in tree

3. Portage dependency solving

Was this discussed somewhere? Could you point me there?

--
Jauhien



signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

hasufell
On 11/07/2014 09:55 PM, Jauhien Piatlicki wrote:

> 07.11.14 21:44, hasufell написав(ла):
>> On 11/07/2014 08:56 PM, Jauhien Piatlicki wrote:
>>
>> Every time people compare portage to paludis I read stuff like "but
>> paludis is slower". That is incomplete information to put it diplomatic.
>>
>> Do you really care so much about speed that you don't mind wrong results?
>>
>
> My original question was about Portage being too slow. And Paludis came out just as an alternative.
>
> And I would like to see a detailed discussion about what's wrong from the point of view of correctness with:
>
> 1. PMS
>
> 2. ebuilds in tree
>
> 3. Portage dependency solving
>
> Was this discussed somewhere? Could you point me there?
>

The first thing that comes to my mind is dynamic dependencies. They are
wrong and that has been discussed recently on this ML.

If you have ever switched from portage to paludis on a full-grown
system, then you know how much bad data and missing
updates/blockers/dependencies are hidden.

However, it seems that this issue is being addressed by the portage
team, afair.

Next thing that comes to my mind is: indeterministic results. I'v had
LOTS of them with portage. You run an emerge, abort. You run it again...
and woosh, different result.
I'v not hit that case yet with paludis, unless I ran it with different
configuration options.

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Zac Medico-2
On 11/07/2014 01:04 PM, hasufell wrote:
> Next thing that comes to my mind is: indeterministic results. I'v had
> LOTS of them with portage. You run an emerge, abort. You run it again...
> and woosh, different result.

This is a result of the solution space being quite large, combined with
hash randomization (and possibly some other forms of randomization). You
will probably notice this sort of randomization more for failed
dependency calculations than for successful dependency calculations.
Successful dependency calculations will almost always result in
reproducible results.
--
Thanks,
Zac

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Francesco Riosa-3
In reply to this post by hasufell
Il 07/11/2014 20:08, hasufell ha scritto:
> Also, I don't understand these discussions. The time dependency
> resolving takes is marginal compared to the whole update process, no
> matter what PM you use.
"The time dependency resolving takes is marginal compared to the whole
update process "
^^^ this is an utter lie for frequent updates




Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Andrew Savchenko-2
In reply to this post by Ciaran McCreesh-4
On Fri, 7 Nov 2014 19:21:01 +0000 Ciaran McCreesh wrote:
> On Fri, 07 Nov 2014 19:54:08 +0100
> Matthias Maier <[hidden email]> wrote:
> > Currently, for portage just to decide that nothing has to be done on
> > my machine takes around 1 minute.
>
> Are you running with or without metadata cache? If you're running
> without, it's going to be slow independently of the resolution
> algorithm...

Wanna ~20-30 minutes with sqlite metadata cache enabled?
Try on Intel Atom N270 with 2800 packages installed.
Dependency resolution is utterly slow.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Andrew Savchenko-2
In reply to this post by hasufell
On Fri, 07 Nov 2014 20:08:12 +0100 hasufell wrote:

> On 11/07/2014 07:54 PM, Matthias Maier wrote:
> >> Well, you're not comparing like with like. Paludis with "everything
> >> turned off" does more than Portage with "everything turned on". If all
> >> you're looking for is the wrong answer as fast as possible, there are
> >> easier ways of getting it...
> >
> > The last time I compared the resolver speed of portage and paludis both
> > needed almost the same time.
> >
> > Do you have a speed comparison with a similar feature set of both? (Or,
> > alternatively, the speedup one gains by tuning paludis to be as fast as
> > possible).
> >
>
> I think you didn't get the idea: it doesn't make much sense to compare
> the speed if the correctness differs.
>
> Also, I don't understand these discussions. The time dependency
> resolving takes is marginal compared to the whole update process, no
> matter what PM you use.
Time required for user's attention differs from time required for
CPU to work. During main update process portage just works for a
few days (and then I have to deal with failed packages, but that's
another story).

As for dependency resolution during world update, this process is
usually iterative: portage failes due to some unsatisfied USE
flags, blocks, circular deps and so on. After resolving one of this
problems emerge needs to be run one more time and so on. On old
hardware iteration takes up to an hour (even with sqlite cache! 1
hour of CPU time), so a day or sometimes even two needed just to
start actual build process! Now take into account that not always
it is possible to spend all day just to start package's building,
so world updates spans to weaks...

With 10x times faster deps resolver it will be possible to handle
all these issues in a few hours and let it contiue update on its
own.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Patrick Lauer
In reply to this post by hasufell
On 11/08/2014 03:08 AM, hasufell wrote:

> On 11/07/2014 07:54 PM, Matthias Maier wrote:
>>> Well, you're not comparing like with like. Paludis with "everything
>>> turned off" does more than Portage with "everything turned on". If all
>>> you're looking for is the wrong answer as fast as possible, there are
>>> easier ways of getting it...
>>
>> The last time I compared the resolver speed of portage and paludis both
>> needed almost the same time.
>>
>> Do you have a speed comparison with a similar feature set of both? (Or,
>> alternatively, the speedup one gains by tuning paludis to be as fast as
>> possible).
>>
>
> I think you didn't get the idea: it doesn't make much sense to compare
> the speed if the correctness differs.
>
> Also, I don't understand these discussions. The time dependency
> resolving takes is marginal compared to the whole update process, no
> matter what PM you use.
>
*ahem*

On my old notebook, which luckily suicided thanks to Lenovo's built in
obsolete device detection ...

emerge -auNDv world took up to 35 minutes

So, if something like RUBY_TARGETS or a random useflag changes, it takes
me literally DAYS to figure out a valid solution where portage can
figure out an upgrade path.

No, it's not marginal.

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Ciaran McCreesh-4
In reply to this post by Francesco Riosa-3
On Sat, 08 Nov 2014 09:29:52 +0100
"[hidden email]" <[hidden email]> wrote:
> "The time dependency resolving takes is marginal compared to the whole
> update process "
> ^^^ this is an utter lie for frequent updates

Uh, how long are your resolves taking?

--
Ciaran McCreesh

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Ciaran McCreesh-4
In reply to this post by Jauhien Piatlicki-2
On Fri, 07 Nov 2014 20:57:41 +0100
Jauhien Piatlicki <[hidden email]> wrote:
> What;s wrong with input? PMS itself or how do maintainers write
> ebuilds? Could you explain?

A mixture of both. Gentoo developers like writing eclasses that write
unnecessarily clever, highly messy and technically incorrect dependency
strings (see how Perl and Ruby are done, for prime examples). Doing
this kind of thing well requires support from PMS, so developers can
express what they want to say directly rather than via some convoluted
mess of nested ||s, []s, slot abuse and faked range dependencies.
However, it's currently culturally more acceptable to try to make
yourself look clever by writing the new "world's most convoluted family
of eclasses", so developers aren't asking for the features they need.

In a way, this brings us back to SAT and CNF. Although you *can* encode
this kind of thing in SAT (or rather, in QSAT...), the encoding is
utterly opaque and doesn't lend itself to a good algorithm. The
dependencies some developers are writing are nearly as bad.

--
Ciaran McCreesh

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Ciaran McCreesh-4
In reply to this post by hasufell
On Fri, 07 Nov 2014 22:04:57 +0100
hasufell <[hidden email]> wrote:
> Next thing that comes to my mind is: indeterministic results. I'v had
> LOTS of them with portage. You run an emerge, abort. You run it
> again... and woosh, different result.
> I'v not hit that case yet with paludis, unless I ran it with different
> configuration options.

You won't hit this with Paludis if you don't change anything between
runs.

--
Ciaran McCreesh

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Francesco Riosa-3
In reply to this post by Ciaran McCreesh-4
Il 08/11/2014 14:35, Ciaran McCreesh ha scritto:
> On Sat, 08 Nov 2014 09:29:52 +0100
> "[hidden email]" <[hidden email]> wrote:
>> "The time dependency resolving takes is marginal compared to the whole
>> update process "
>> ^^^ this is an utter lie for frequent updates
> Uh, how long are your resolves taking?
>
I've updated the system half hour ago it's empty, but this system can
compile and install a good number of packages in 3 minutes.
Obviously this is without tuning the filesystem, with rotational disks
_and_ 3 overlays (which slow down a lot) plus it has more than 2000
packages installed
So I would not call this marginal at all. Not even if it was one minute,
for attended upgrades is annoying.

gentoo ~ # /usr/bin/time --verbose     emerge -uDpN @world

These are the packages that would be merged, in order:

Calculating dependencies... done!
        Command being timed: "emerge -uDpN @world"
        User time (seconds): 178.45
        System time (seconds): 1.58
        Percent of CPU this job got: 100%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 2:59.88
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 2470064
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 168879
        Voluntary context switches: 11
        Involuntary context switches: 1568
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0




Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

hasufell
In reply to this post by Patrick Lauer
On 11/08/2014 02:24 PM, Patrick Lauer wrote:

> On 11/08/2014 03:08 AM, hasufell wrote:
>> On 11/07/2014 07:54 PM, Matthias Maier wrote:
>>>> Well, you're not comparing like with like. Paludis with "everything
>>>> turned off" does more than Portage with "everything turned on". If all
>>>> you're looking for is the wrong answer as fast as possible, there are
>>>> easier ways of getting it...
>>>
>>> The last time I compared the resolver speed of portage and paludis both
>>> needed almost the same time.
>>>
>>> Do you have a speed comparison with a similar feature set of both? (Or,
>>> alternatively, the speedup one gains by tuning paludis to be as fast as
>>> possible).
>>>
>>
>> I think you didn't get the idea: it doesn't make much sense to compare
>> the speed if the correctness differs.
>>
>> Also, I don't understand these discussions. The time dependency
>> resolving takes is marginal compared to the whole update process, no
>> matter what PM you use.
>>
> *ahem*
>
> On my old notebook, which luckily suicided thanks to Lenovo's built in
> obsolete device detection ...
>
> emerge -auNDv world took up to 35 minutes
>
> So, if something like RUBY_TARGETS or a random useflag changes, it takes
> me literally DAYS to figure out a valid solution where portage can
> figure out an upgrade path.
>
> No, it's not marginal.
>

So we are back to the initial discussion: fix the input instead of
making the resolver even worse. You can't have both bad input and a fast
_correct_ resolver.

So you choose between "good enough results which may not be what you
want" and "pretty good results with lots of things to figure out
yourself, because of the input and because the resolver does not make
random assumptions about what you want".

Both solutions s**k, tbh.

I'd just like people to look at the whole picture and don't keep PM
discussions narrow-minded by all this NIH crap.

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Hilco Wijbenga
In reply to this post by Ciaran McCreesh-4
On 8 November 2014 05:40, Ciaran McCreesh
<[hidden email]> wrote:

> On Fri, 07 Nov 2014 20:57:41 +0100
> Jauhien Piatlicki <[hidden email]> wrote:
>> What;s wrong with input? PMS itself or how do maintainers write
>> ebuilds? Could you explain?
>
> A mixture of both. Gentoo developers like writing eclasses that write
> unnecessarily clever, highly messy and technically incorrect dependency
> strings (see how Perl and Ruby are done, for prime examples). Doing
> this kind of thing well requires support from PMS, so developers can
> express what they want to say directly rather than via some convoluted
> mess of nested ||s, []s, slot abuse and faked range dependencies.
> However, it's currently culturally more acceptable to try to make
> yourself look clever by writing the new "world's most convoluted family
> of eclasses", so developers aren't asking for the features they need.
>
> In a way, this brings us back to SAT and CNF. Although you *can* encode
> this kind of thing in SAT (or rather, in QSAT...), the encoding is
> utterly opaque and doesn't lend itself to a good algorithm. The
> dependencies some developers are writing are nearly as bad.

So would it make sense then to move to a more declarative ebuild
model? Or just a "better" model?

Both Portage and Paludis at some point figure out what they think is
needed to install an ebuild. At that point, they could emit an ebuild
in a "new and improved" model? I have no doubt that this scheme would
fail utterly for many of the more complex/convoluted ebuilds but if it
worked for, say, 80% then the work to improve the tree would be
drastically reduced.

(I only write the simplest of ebuilds so I'm undoubtedly
oversimplifying but I thought I would throw this idea out there.)

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Ciaran McCreesh-4
On Sat, 8 Nov 2014 10:11:13 -0800
Hilco Wijbenga <[hidden email]> wrote:
> So would it make sense then to move to a more declarative ebuild
> model? Or just a "better" model?

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.

--
Ciaran McCreesh

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Matthias Dahl
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?

Thanks a lot,
Matthias


Reply | Threaded
Open this post in threaded view
|

Re: 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.

Reply | Threaded
Open this post in threaded view
|

Re: 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.

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Duncan-42
In reply to this post by Andrew Savchenko-2
Andrew Savchenko posted on Sat, 08 Nov 2014 13:56:21 +0300 as excerpted:

> Wanna ~20-30 minutes with sqlite metadata cache enabled?
> Try on Intel Atom N270 with 2800 packages installed. Dependency
> resolution is utterly slow.

Hmm.  My netbook's an Atom N270 also.  But I use a build-image chroot on
my main 6-core AMD bulldozer for building and just rsync over, and I only
have ~800 packages installed, so I fortunately don't have the N270 speed
issues to deal with for package resolution and build.

But I've more or less decided to buy a new netbook level x86_64 one of
these days and shelve the 32-bit-only N270, so I can use pretty much the
same packages on both the workstation and the (new) netbook.  Maybe then
I'll actually keep the netbook current instead of letting it go a year or
more between updates.  It's just a matter of actually doing it.  Maybe
this Black-Friday or Cyber-Monday...

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

Rich Freeman
In reply to this post by hasufell
On Sat, Nov 8, 2014 at 2:48 PM, hasufell <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Portage dependency solving algorithm

hasufell
On 11/08/2014 10:30 PM, Rich Freeman wrote:

> On Sat, Nov 8, 2014 at 2:48 PM, hasufell <[hidden email]> 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.
>

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.

1234