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