[Haskell-cafe] Why does cabal select base-3.0.3.2 when base-4.2.0.0 is available?

[Ivan Lazar Miljenovic]

Bjorn Buckwalter <bjorn.buckwalter at gmail.com> writes:
> So what would be the fix, to set an upper bound on base?

The fix is to have the maintainer check whether or not the package
builds with base-4 (you can do this the old manual way using runhaskell
Setup.hs).  If it does, then specify that it does so, e.g.:

  base < 5

The upper bound is needed (and Hackage now enforces this) because too
many packages have this same problem: the maintainers blindly assume
that the package will build for all time, and then it dies the next time
a new major version of the base package is released.  Note that some
people cheat by having dependencies like "base < 10" as Hackage will
accept this because there is indeed an upper bound, but this just causes
problems in the future (Don Stewart had "base < 5" for a release of
ghc-core which then failed to build with base-4).

> Is the general recommendation that all packages should specify upper
> bounds on all dependencies (if so why doesn't Cabal tell us?)?

This is the eventual goal and is why Duncan Coutts is pushing the
Package Versioning Policy
(http://www.haskell.org/haskellwiki/Package_versioning_policy) as you
can tell from the version (if it is followed correctly) when the API has
changed in a backwards-incompatible fashion.

At the moment, however, Hackage - not Cabal - enforces the requirement
on the base package for all new packages uploaded.  This isn't made
compulsory for all package dependencies as 1) it is base dependencies
that typically cause most of the breakages and 2) not all packages
follow the PVP and thus doing this doesn't always make sense (e.g. some
packages use a date-based versioning system for some reason).

> I can see that this would make some sense as a package might be broken
> by an API change in its dependencies. On the other hand I can also see
> it causing headaches occasionally...

Right, see the recent thread started by John Goerzon "The instability of
Haskell libraries" which is in part to do with this problem.  At the
moment when a dependency has a major version update but is still
buildable by your package you have to create a new release to let it use
that updated dependency, which is a pain and isn't always done promptly
by maintainers.  Possibly the best way towards fixing this is the
proposal to take the Cabal files outside of the tarballs and distribute
them separately; that way they can be edited without affecting the
tarball in question (thus making them even more like Gentoo's ebuild or
Arch's PKGBUILD files).

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com