headers
Dinko Tenev | 13 Dec 10:23

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
Permalink | Reply |
headers
Duncan Coutts | 13 Dec 13:11

Re: Portage slots for GHC?

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
(Continue reading)

Permalink | Reply |
headers
kahl | 13 Dec 17:06
Favicon

Re: Portage slots for GHC?

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
Permalink | Reply |
headers
Duncan Coutts | 13 Dec 17:44

Re: Portage slots for GHC?


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
(Continue reading)

Permalink | Reply |
headers
kahl | 13 Dec 18:09
Favicon

Re: Portage slots for GHC?

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:???"
 >
(Continue reading)

Permalink | Reply |
headers
Duncan Coutts | 14 Dec 00:01

Re: Portage slots for GHC?


On Thu, 2007-12-13 at 17:09 +0000, kahl <at> 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
Permalink | Reply |

Gmane