Portage slots for GHC?
Hi, I'm using GHC on Gentoo, and so far I've had to stay clear of GHC 6.6, because I've also installed stuff depending on 6.4.2, like wxHaskell, for instance. Now I see a new version of mtl, which I also have installed, depends on 6.6.1, while all of the rest of the stuff is "lagging behind" with a dependency on 6.4.2. Of course, I can easily solve the problem partially by masking out the new version for mtl, but this is going to become a major inconvenience with new versions of GHC and its dependents. What I'm getting at is, can we please have separate slots for GHC 6.4.2 and 6.6 on portage? Cheers, Dinko
Oops, I sent this previously from my @gentoo address so it got rejected by the mailing list. Re-sending my reply in case anyone other than Dinko Tenev is interested. On Thu, 2007-12-13 at 11:25 +0200, Dinko Tenev wrote:
Hi,
I'm using GHC on Gentoo, and so far I've had to stay clear of GHC 6.6, because I've also installed stuff depending on 6.4.2, like wxHaskell, for instance.
On that specific issue, we prodded the wxHaskell team the other day complaining that the current release only works with ghc-6.4.2 and old with old versions of wxGTK. They are apparently looking at doing a release that'll work with recent wxGTK and ghc-6.6 and 6.8.
Now I see a new version of mtl, which I also have installed, depends on 6.6.1, while all of the rest of the stuff is "lagging behind" with a dependency on 6.4.2.
Yes, it's annoying. The only things left that do not work with 6.6 are hs-plugins and wxHaskell.
Of course, I can easily solve the problem partially by masking out the new version for mtl, but this is going to become a major inconvenience with new versions of GHC and its dependents.
Yep.
What I'm getting at is, can we please have separate slots for GHC 6.4.2 and 6.6 on portage?
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. -- Duncan Coutts : Gentoo Developer (Haskell team)
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. Wolfram
On Thu, 2007-12-13 at 16:06 +0000, kahl@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: SLOT="${GHC_PV}-${PV}" 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: DEPEND="dev-haskell/foo:???" it's supposed to be the same ghc slot as our own slot is. But we can't get that information. Duncan
Duncan Coutts wrote:
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:
SLOT="${GHC_PV}-${PV}"
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:
DEPEND="dev-haskell/foo:???"
it's supposed to be the same ghc slot as our own slot is. But we can't get that information.
Until portage actually can do this in a better way, you would have to multiply ebuilds (probably each with common import and a one-line variable setting) (I don't know the exact restrictions on portage version strings): === mtl-common-X.Y.Z === ... SLOT="${GHC_PV}-${PV}" DEPEND="dev-haskell/ghc-${GHC_PV}" ... === mtl-ghc.6.6..X.Y.Z === GHC_PV=ghc.6.6 include mtl-common-X.Y.Z === mtl-ghc.6.8..X.Y.Z === GHC_PV=ghc.6.8 include mtl-common-X.Y.Z One day, you may even want mtl for other compilers... Wolfram
On Thu, 2007-12-13 at 17:09 +0000, kahl@cas.mcmaster.ca wrote:
Until portage actually can do this in a better way, you would have to multiply ebuilds (probably each with common import and a one-line variable setting) (I don't know the exact restrictions on portage version strings):
Right that'd be possible, to include the slot information into the ebuild name, but unfortunately that would be against gentoo versioning policy. We're supposed to have the ebuild name be the package name and use slotting for the other stuff. We have talked to portage devs about our problem. We'll have to wait, or all jump ship to NixOS which can do this stuff properly.
One day, you may even want mtl for other compilers...
Indeed, we'd want to slot on the compiler (and for ghc the compiler version) and on the library version. Then we only want to satisfy other haskell library dependencies from within the same compiler slot. Duncan
participants (3)
-
Dinko Tenev -
Duncan Coutts -
kahl＠cas.mcmaster.ca