PVP proposal: no upper bounds on non-upgradeable packages

[Herbert Valerio Riedel]

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.