Bjorn Buckwalter
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@gmail.com IvanMiljenovic.wordpress.com