Limiting size of global package database

Michael Snoyman michael at
Wed Dec 31 14:10:37 UTC 2014

tl;dr: Now that ghc (the library) doesn't depend on Cabal (the library),
can we remove Cabal from the global package database installed with GHC?

A problem that comes up quite a bit for users of GHC is conflicting package
versions versus the version of a package that shipped with GHC. Some
examples I've run into in the past include binary-0.7/GHC-7.6, and
bytestring0-0.10/GHC-7.4. This is problematic for two reasons:

1. End users can be confused by having multiple versions of a package
installed (one global, one user). I've seen at least a dozen questions on
Stack Overflow, Reddit, and mailing lists about things like "ByteString is
not bytestring-".
2. Any packages depended on by the ghc package can be very dangerous to
upgrade, as then you're blocked from using the ghc package with the new
version. This most often comes into play with doctest, though I've been
affected by it on other projects as well.

For both of these reasons, I think we should limit the number of packages
included in the global package database. One seemingly small step we could
do on that front is not include extraneous packages. In GHC 7.10rc1, that
includes Cabal and xhtml: both packages are in the global package database,
but could just as easily be removed from there and installed by users. The
motivation for that would be to avoid problem (1) above.

I realize that this change wouldn't affect point (2) above at all. Frankly,
that's the issue that causes me quite a bit more trouble, and I'd love to
see it resolved somehow, but it's unlikely to occur during the GHC 7.10
window. I'm writing this email now because I think there's a chance of
resolving the smaller issue immediately, but I'd like to explore the wider
issue of ghc-the-library dependencies for GHC 7.12.

I've opened up an issue[1] on Stackage's issue tracker about this as well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list