On 2014-04-11 at 00:27:31 +0200, Edward Kmett wrote: [...]
That said, this should be rather mitigated going forward by:
https://github.com/hvr/cabal/commit/65e9b88bc849e76040ed7947591ea7172cd02db5
which closes out
https://github.com/haskell/cabal/issues/1444
and
https://github.com/haskell/cabal/issues/667
So in essence, it _is_ being fixed in cabal.
Btw, the case of 'template-haskell' could be considered another data-point in the upper-bounds debate: Cabal would have been able to do a better job, if 'template-haskell' would have set tighter version-bounds :-) If you look at the previous versions, on http://hackage.haskell.org/package/template-haskell 'template-haskell' had the obviously incorrect constraint build-depends: base >= 4.2 && < 5, pretty, containers from version 2.4.0.1 till 2.8.0.0; only starting with 2.9.0.0 it got a tighter one, specifically build-depends: base == 4.7.*, containers == 0.5.*, pretty == 1.1.* that will keep Cabal from even attempting to install template-haskell-2.8.0 on GHCs prior to GHC 7.8.1, *but* it wouldn't keep GHC 7.8.1 from installing versions of 'template-haskell' prior to 2.8.0.0 So we have to resort to declare 'template-haskell' explicitly in cabal-install's solvers as being a non-upgradable package as a hack, instead of being able to rely on the .cabal meta-data to direct Cabal's solver. PS: Strictly speaking, it seems to me 'template-haskell' can actually be upgraded in theory, GHC will use the latest installed version as its wired-in package (if understand the code correctly), but there was no need for updating 'template-haskell' between GHC releases in the past.