Cabal and GHC

Michael Snoyman michael at
Thu Nov 22 11:39:50 CET 2012

On Thu, Nov 22, 2012 at 10:32 AM, Simon Peyton-Jones
<simonpj at>wrote:

> Michael Snoyman wrote a blog post about Solving Cabal Hall, which came
> across via the peerless Haskell Weekly News.
> But I'd be unlikely to return there so I'm posting this to the libraries
> and cabal-devel lists.
> I'm not deep in Cabal lore, but it seems to me that there is a fairly easy
> way to do a Lot Better than we are now. Let's go back to "Identifying the
> Problem".  Michael doesn't say, but I'm guessing that Fay depends on
> yesod-platform.  Very well, so Cabal sees
>   I'm installing Fay,
>   which depends on yesod-platform, which dpends on data-default
>   and depends directly on data-default
> If the package database was empty, Cabal would try to figure out a version
> of data-default that is acceptable to both yesod-platform and to Fay.  And
> that's what we want!
> Suppose that Cabal figures out that yesod-platform-2.7 and
> data-default-0,4 would work.  Then, in an empty package database, it could
> just go ahead and install those.  But in your example, the database isn't
> empty; we have already isntalled yesod-platform-2.7, dependin gon
> data-default-0.5.  And (here's the rub) you can only have
> yesod-platform-2.7 installed once.
> One solution might be
>  1. *un* install yesod-platform-2.7 (depending on data-default-0.5) and
>  2. *re* install it (depending on data-default-0.4).
> But that would break any programs that use both yesod-platform-2.7 and
> data-default-0.5.
> The solution is obvious: we should make it possible to instally
> yesod-platform-2.7 twice,
>   once version depending on data-default-0.4
>   once version depending on data-default-0.5.
> Now, if Cabal can figure out a plan based on an empty database, it can
> deliver on that plan even in a non-empty database, without messing up any
> existing installations.
> Of course, if Fay depends exclusively on data-default-0.4, and
> yesod-platform depends exclusively on data-default-0.5, then they genuinely
> are incompatible, and Cabal can and should say so. That's not Cabal Hell.
>  That's just saying that the package authors have *specified* that they are
> incompatible.
> Summary.  I may be way off beam here, but I think we can easily make
> things way better than they are.  By "easily" I mean with just design and
> implementation work.  That's not free, and no one has any time.... but it's
> well within reach. I'd even been wondering about trying to crowd-fund this
> development so that Well Typed can do it.  But let's first see if it'd
> solve the problem.
> There must be a wiki page somewhere that articulates the challenge, points
> to blog posts about it, and discusses solutions.
> Simon
> _______________________________________________
> Libraries mailing list
> Libraries at

Hi Simon,

Having GHC support multiple copies of the same package/version would
certainly be a step in the right direction. It still wouldn't completely
address the goals I'm getting at in my blog post. What I'm really aiming
for overall is to provide users with a stable, vetted set of packages that
are known to work well together. But for those of us who will still be
using plain Hackage, this improvement would be very helpful.

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

More information about the Libraries mailing list