[Hackage] #470: bad error message when a package transtively depends on two versions of the same one

[Hackage]

#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