Hi Manfred.
I did 'ghc-pkg check' which showed nothing. Fine!
Then I did 'cabal install gitit' and after successfully installing gitit I ran 'ghc-pkg check' again and got:
[lots of broken packages deleted] Yes. That can happen with current cabal-install.
Why is this happening?
The dependency resolution algorithm will try to make a consistent install plan that allows gitit to be run. However, in order to achieve that, it may decide that it's necessary to reinstall some existing packages in a new configuration (with other dependency or flag settings). Such reinstalls will then overwrite the previous package in the store, and if that previous package was depended on by something else, these other things will break. While ghc-pkg currently allows both foo-1.0 and foo-2.0 to be in the store at the same time, it doesn't allow two different configurations of foo-2.0 in the store at the same time.
Could I prevent it somehow?
Currently, you can only discover the danger of this happening in advance: You can run "cabal install --dry-run -v gitit", and then you'll get an annotated install plan printed out. If you notice lines like HTTP-4000.1.1 (reinstall) changes: network-2.3.0.2 -> 2.2.1.10 then you are in danger. If you only see lines that say "(new package)" or "(new version)", you're safe. In the new dependency resolver I'm currently implementing for Cabal, which you can preview at http://darcs.haskell.org/cabal-branches/cabal-modular-solver/ there will be an option "--avoid-reinstalls" that tries to avoid reinstalls (but perhaps at the cost of selecting older versions of certain packages to avoid them). Also, the next release of Cabal will probably add a warning if an install plan contains reinstalls. The proper solution would be to lift the limitation in the GHC package store and allow arbitrarily many variants of packages to coexist peacefully, so that even a "reinstall" won't have to remove an old version. I hope we're getting around to implement this sooner or later. Cheers, Andres