A detailed discussion is in this haskell-cafe thread:
I'm not entirely sure if this is a pure cabal issue. In particular the version of ghc currently installed on hackage and/or the setup on hackage is also of suspect. In relation to cabal, Ross says:
With ghc 7.4.1, cabal-install 0.13.3 and Cabal 1.14.0,
% cabal install --avoid-reinstalls sbv-2.2
fails to find a plan without reinstalls, and recommends --solver=modular.
% cabal install --solver=modular --avoid-reinstalls sbv-2.2
reinstalls template-haskell-184.108.40.206, which breaks the GHC installation.
I've added the suggested --constraint='template-haskell==220.127.116.11'
option as a workaround, but it seems the --avoid-reinstalls option is
I haven't seen anything yet that suggests there's a Cabal or cabal-install problem involved. 0.13.3 isn't an official version. I haven't been able to reproduce that cabal-install --avoid-reinstalls suggests a reinstall.
The only issue I can see here is that cabal-install should refuse installing new versions of template-haskell completely, in the same way it refuses to install ghc-prim or base. However, rather than having a large hardcoded list of built-in packages for GHC, I'd like to have a robust algorithm to detect such packages.
Fyi, I've updated all template-haskell releases on hackage to include bounds on base. Maybe this helps.
This looks to have been fixed by updated version bounds on Hackage, so closing. Please reopen if the issue persists.