Hi there, I had something like this before but now I checked explicitly: 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: There are problems in package yesod-form-0.1.0.1: dependency "xss-sanitize-0.2.6-bfb18d04010fadbceea5ba5136c33373" doesn't exist There are problems in package warp-0.4.0.1: dependency "sendfile-0.7.3-1d8424f5c18454ab33888680f53a7340" doesn't exist There are problems in package happstack-state-6.0.0: dependency "hslogger-1.1.4-d65ba05b9e69912e34b53b6153cc40ff" doesn't exist There are problems in package happstack-jmacro-6.0.0: dependency "happstack-server-6.1.3-8a8613c407db656b76de3be81e531fb5" doesn't exist The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. yesod-form-0.1.0.1 warp-0.4.0.1 happstack-state-6.0.0 happstack-jmacro-6.0.0 yesod-0.8.2.1 yesod-auth-0.4.0.2 For example, hslogger was reinstalled for some reason and got a new id. Now it is hslogger-1.1.4-dff59692d8bdac1df0c425c217a20b0c.conf Why is this happening? Could I prevent it somehow? -- Manfred
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
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
Hi again.
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.
Yes, it's somewhat similar, and you did the right thing. If you request pandoc in isolation, it will be built against the versions of its dependencies you already have installed, or, if you don't, against the latest versions of these dependencies. However, gitit introduces additional constraints, and the version of pandoc you get when you ask for it individually currently doesn't meet these constraints. By putting them both as targets on a single command line, you get cabal to make a consistent install plan for both packages. Cheers, Andres
participants (2)
-
Andres Loeh -
Manfred Lotz