[Haskell] cabal conflicting rules
Albert Y. C. Lai
trebla at vex.net
Fri Oct 28 03:51:52 CEST 2011
On 11-10-26 10:40 AM, Ben Millwood wrote:
> I don't think this is foolproof, either. Correct me, anyone else, if
> I'm wrong, but in some cases cabal will want to rebuild your packages
> that came with GHC; sometimes this can involve breaking a package that
> cannot be rebuilt (e.g. the ghc package depends on the directory
> package, if cabal tried to reinstall that for some reason, the ghc
> package would be broken).
Correct, and my http://www.vex.net/~trebla/haskell/sicp.xhtml has an
example in the pigeon drop con section.
That example is difficult to reproduce today, as Hackage hosts far newer
versions now than assumed back then. But you should still read it for
the working principle. (Once upon a time, when hackage frontier versions
matched what I wrote, it was easy to reproduce.)
To reproduce the scenerio today, at the time of writing, try this:
GHC version 7.2.1, comes with
where ghc depends on template-haskell depends on containers.
At the time of writing, Hackage frontier has
where QuickCheck depends on template-haskell depends on containers.
At the bottom of the food chain (containers), Hackage frontier is newer
than what we have installed, but at middle parts of the food chain
(template-haskell), Hackage frontier matches installed versions. All
players are ready for the pigeon drop con!
An upgrade whore comes along to upgrade containers like it is a
cabal install --global containers
Then a benign admin comes along to install QuickCheck because it's
needed and it hasn't been installed:
cabal install --global QuickCheck
(triggers replacing template-haskell-220.127.116.11)
The earth-shattering disaster is complete. ghc-7.2.1 is hosed.
$ ghc -v
Glasgow Haskell Compiler, Version 7.2.1, stage 2 booted by GHC version
package ghc-7.2.1-b200b39a49432181058dc1bbf8fabb95 is unusable due to
missing or recursive dependencies:
More information about the Haskell