[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 
ground-breaking change:

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-

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 mailing list