[Haskell-cafe] Dependencies conflict

[Duncan Coutts]

On Wed, 2009-01-28 at 18:22 +0100, Martijn van Steenbergen wrote:
> Hello,
> 
> $ cabal install category-extras
> Resolving dependencies...
> cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however
> process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0
> 
> What does this message mean? It makes little sense to me -- ghc-6.10.1 
> requires both process ==1.0.1.1 and process ==1.0.1.0?

Yes, that's exactly what it looks like to Cabal which is why it is
horribly confused.

The reason is shadowing between the global and user package dbs. The way
ghc package databses work is that the user one is just slapped on top of
the global one. Like Data.Map.union.

Suppose you've got these packages registered in the global package db:

    A-1
   / |
  /  |
 B-1 |
  \  |
   \ |
    C-1.0.1.0

Now, suppose you register B-1 in the user package db, then it masks the
existing B-1 from the global db. But suppose that you build this
instance against C-1.0.1.1...

    A-1
   / \
  /   \
 B-1   \
  \     C-1.0.1.0
   \       
    C-1.0.1.1

Oh no! Now A-1 appears to depend on two versions of C! The cabal-install
dependency resolver is designed to look for solutions where this does
not happen, but here it's already happened in the installed packages, so
it cannot ever pick the A-1 package as part of an install plan.

It's not just cabal-install that will get confused here. ghc --make will
too. If you're lucky you'll get linker errors. If you're unlucky you'll
get segfaults.

The solution we've been discussing for the next major ghc release is to
track package ABIs and possibly even to allow slotting packages in their
ABI. That would make this problem disappear and generally allow safer
and more flexible management of installed packages.

In the mean time I'm thinking of making the representation of installed
package databases record broken packages. Then when we overlay package
databases we could mark clashes like the above as breaking A-1. We
should also try and get the solver to help us find solutions that avoid
getting into this situation in the first place.

> And, more importantly, how do I solve this?

Look for packages where you have the same version registered in the user
and global package db. Unreigister the user one.


Duncan