On Thu, 23 Jun 2011 11:46:12 +0200
Andres Loeh
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
Thanks for explaining it. I had another issue with optional syntax highlighting support in gitit. The gitit web site says that if it available in pandoc then it is available in gitit too. Then the recommendation is: "To install gitit with highlighting support, first ensure that pandoc is compiled with highlighting support, then install gitit as above: cabal install pandoc -fhighlighting --reinstall cabal install gitit" If I do this it doesn't work because when installing gitit pandoc will be rebuilt again. I did: cabal install git pandoc -fhighlighting --reinstall which helped. I guess this fits also in the explanations you gave me. -- Manfred