Portage slots for GHC?

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Thu Dec 13 11:44:30 EST 2007

On Thu, 2007-12-13 at 16:06 +0000, kahl at cas.mcmaster.ca wrote:
> Duncan Coutts wrote:
>  > 
>  > Sadly not because portage is not clever enough to deal with the kind of
>  > dependencies you end up with by doing that. Portage does not know that
>  > some libs are installed for one ghc and some for another, so it'd try
>  > and satisfy a dependency for mtl using the mtl you'd installed for
>  > ghc-6.4.2 when in fact you were building something for 6.6.1.
>  > 
>  > You may have heard of other new portage features that sound like they'd
>  > help, they don't. We've thought about this a lot and it is not feasible
>  > in with the current portage.
>  > 
>  > We could slot multiple versions of a lib for the same ghc, but not slot
>  > ghc itself.
> Why not library slots named
> ghc-6.4
> ghc-6.6
> ghc-6.8
> (or finer), each depending on the repective compiler slot?
> The different slots of gtk+ also depend on different slots of glib.

But those are actually different versions of the Gtk+ library. Our
situation is worse, we have the exact same library version slotted for
multiple versions of ghc.

We'd want to be able to say something like:


to slot on the ghc version and library version. But where does ${GHC_PV}
come from?

Well, suppose we could do that, now how do we specify the deps:


it's supposed to be the same ghc slot as our own slot is. But we can't
get that information.


More information about the Glasgow-haskell-users mailing list