[Haskell] package maintainers: updating your packages to work with GHC 6.8.1

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Sun Nov 4 22:12:29 EST 2007

If you maintain a Haskell package this is for you.

So now that GHC 6.8.1 is out you'll want to test your package with it.
We'd especially like maintainers of packages that are distributed on
hackage.haskell.org to test their packages and update them as necessary.
However we would appreciate it if your packages will still work with GHC
6.6.x, so read below for details on how to do that.

You'll most likely find that your package fails to build with GHC 6.8.1
with an error message like this:

  Could not find module `Data.Map': it is a member of package
  containers-, which is hidden.

This is the first symptom of the change in the base library in GHC
6.8.1. Several parts of the old base library got split out into separate
packages. For example Data.Map is now in the containers package.
Unfortunately this means most packages need updating.

Of course you'd also like to make your packages continue to work with
GHC 6.6.x (and perhaps older). If you go and just add containers to your
package's build-depends then it will no longer work with GHC 6.6.x or
older. So the solution at the moment is to use Cabal configurations like

flag splitBase
  description: Choose the new smaller, split-up base package.
  if flag(splitBase)
    build-depends: base >= 3, containers
    build-depends: base < 3

Since this uses a new Cabal feature you'll have to make your packages
require Cabal-1.2 or later:

cabal-version: >=1.2

This is ok since Cabal-1.2.x comes with ghc-6.8 and can also be
installed from hackage for older ghc versions.

For a bigger example see Cabal's own .cabal file:

The new Cabal syntax is explained in the Cabal user guide:

This is all explained in more detail on the wiki:

And the details of other api changes in the libraries are in the GHC
6.8.1 release notes:

A list of packages on hackage that currently fail to build with GHC
6.8.1 is here:

We realise that this change is rather disruptive, requiring changes in
each package. We've started a wiki page with ideas on how to avoid this
in future when the base package is shrunk again.

(Cabal release manager)

More information about the Haskell mailing list