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.
