[Hackage] #470: bad error message when a package transtively depends on two versions of the same one
#470: bad error message when a package transtively depends on two versions of the same one ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ The following error appears like nonsense: {{{ cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.0 however process-1.0.1.0 was excluded because ghc-6.10.1 requires process ==1.0.1.1 }}} It actually means that there's some package ghc depends on that now is built against the newer process. It should tell the name of the other package(s), too. This is made worse by user-installed packages of the same version shadowing global ones, in this case there is no real error. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/470 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#470: bad error message when a package transtively depends on two versions of the same one ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by duncan): * difficulty: unknown => hard (< 1 day) Comment: Replying to [ticket:470 guest]:
It actually means that there's some package ghc depends on that now is built against the newer process. It should tell the name of the other package(s), too.
That's true in this case, I'm not sure there is any particular package to identify in general. We can identify the whole chain of packages involved in the conflict, though I don't know if it would clarify the situation.
This is made worse by user-installed packages of the same version shadowing global ones, in this case there is no real error.
There is a real error but yes it is caused by the user package shadowing the global one. It is not just cabal-install's constraint solver that bumps into this error, `ghc --make` will do the exact same thing and try to link the `ghc` package against the wrong version of one of its dependencies (the one from the user package that is doing the shadowing). The short term solution is to modify the code for overlaying package databases to mark packages as broken when one of their dependencies get shadowed. This requires extending the representation of the installed packages to record if a package is present but broken (which is generally useful info to have around since packages can be broken for a number of reasons like missing dependencies). The long term solution is to identify installed packages by their ABI hash. Then this problem neatly goes away. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/470#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#470: identify and exclude broken or unusable packages when constructing and merging package dbs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by duncan): * summary: bad error message when a package transtively depends on two versions of the same one => identify and exclude broken or unusable packages when constructing and merging package dbs Comment: We should identify these broken and unusable packages when constructing and merging package dbs. Then when solving we should add exclude constraints on such packages. If those packages are then needed then we should report the reason they were excluded. It may also be worth warning whenever we detect this situation at all, even if we do not need the packages in question. Something like `ghc-pkg check` perhaps to do a global package consistency check. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/470#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage