[Hackage] #470: bad error message when a package transtively
depends on two versions of the same one
Hackage
trac at galois.com
Thu Jan 22 17:13:19 EST 2009
#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
More information about the cabal-devel
mailing list