Hi all,
There is now a ghc 6.4-1 in Debian experimental (should be functionally equivalent to the Haskell Unsafe one except with a few more things in /usr/bin, most notably runhaskell).
I'm told we'd need to have all packages for all arches in unstable by 2 weeks time in order to get ghc 6.4 in sarge. I'm not sure this we're going to manage this, but I guess we may as well press on regardless. Reports, both good and bad, on whether ghc 6.4 successfully compiles Haskell packages in Debian (and whether the results actually work) would be useful in this.
Also useful would be similar reports for non-trivial programs and libraries not (especially those not /yet/) in Debian and an indication of how important people think having 6.4 in sarge is.
(Isaac, John, IIRC you are the guys who have worked on cabal / autodebianising cabal packages, so I'm particularly interested in your answers to the following)
Should I split/rename ghc6-hopengl into libghc6-OpenGL-dev and libghc6-GLUT-dev? Or should I leave those names for a separate package to use later? And if the latter, should ghc6-hopengl "Provide: libghc6-OpenGL-dev, libghc6-GLUT-dev"?
Should the ghc6 package provide libghc6-$foo-dev for each of the following?: rts, base, haskell98, template-haskell, unix, Cabal, parsec, haskell-src, network, QuickCheck, HUnit, mtl, fgl, X11, HGL, stm, readline, (lang), (concurrent), (posix), (util), (data), (text), (net), (hssource) (are the ones in parentheses deprecated? (from ghc-pkg -l output))
My opinion is I shouldn't do the split+rename, but should provide everything not in parentheses (although I'm not sure about rts).
At some point we're also going to have to decide whether profiling libraries go in the same package or in a -prof package. Does cabal make it easy to make profiling libraries, BTW?
While I'm here, if anyone's interested in working on the nhc98 bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283024&repeatmerged=no then that would be great; I'm afraid I don't have the time to take on such development ATM :-(
Thanks Ian
On Mon, Mar 14, 2005 at 09:54:20PM +0000, Ian Lynagh wrote:
Reports, both good and bad, on whether ghc 6.4 successfully compiles Haskell packages in Debian (and whether the results actually work) would be useful in this.
Also useful would be similar reports for non-trivial programs and libraries not (especially those not /yet/) in Debian and an indication of how important people think having 6.4 in sarge is.
I was going to say that it's not all that important. I suppose that remains true.
However, I think it is critical that it go into sid ASAP, and then it can fall into sarge if it works.
However, the new hugs is in sid now, and I have seen some incompatibilities between existing code and hugs.
It will be a nightmare to maintain source packages intended to be built with both hugs and ghc, and make them usable with both the new hugs and ghc 6.2. So I for one would welcome ghc 6.4 in sid ASAP.
Should I split/rename ghc6-hopengl into libghc6-OpenGL-dev and libghc6-GLUT-dev? Or should I leave those names for a separate package to use later? And if the latter, should ghc6-hopengl "Provide: libghc6-OpenGL-dev, libghc6-GLUT-dev"?
I have no strong opinion on that, and in any case, you may want to wait with that until post-sarge anyway. I just used that naming scheme because it was the one suggested in the draft haskell policy.
Should the ghc6 package provide libghc6-$foo-dev for each of the following?: rts, base, haskell98, template-haskell, unix, Cabal, parsec, haskell-src, network, QuickCheck, HUnit, mtl, fgl, X11, HGL, stm, readline, (lang), (concurrent), (posix), (util), (data), (text), (net), (hssource) (are the ones in parentheses deprecated? (from ghc-pkg -l output))
I would say there is no need to do that, since we can just depend on ghc and get the right thing, like we do now.
The exception may be Cabal, but I don't know enough about what's going on to have a useful opinion. Isaac?
My opinion is I shouldn't do the split+rename, but should provide everything not in parentheses (although I'm not sure about rts).
I don't think you really need to. A Provide is only useful if there are several ways to satisfy a dependency, which there really aren't here.
At some point we're also going to have to decide whether profiling libraries go in the same package or in a -prof package. Does cabal make it easy to make profiling libraries, BTW?
Another one for Isaac
-- John
On Tue, Mar 15, 2005 at 02:48:57PM -0600, John Goerzen wrote:
However, the new hugs is in sid now, and I have seen some incompatibilities between existing code and hugs.
It will be a nightmare to maintain source packages intended to be built with both hugs and ghc, and make them usable with both the new hugs and ghc 6.2. So I for one would welcome ghc 6.4 in sid ASAP.
Isaac, are there other advantages to having the new hugs in sarge without the new ghc/nhc98 that outweigh this problems, or should we file a dummy RC bug to keep it out of sarge until ghc 6.4 and nhc98 1.18 are ready to go in?
Should the ghc6 package provide libghc6-$foo-dev for each of the following?: rts, base, haskell98, template-haskell, unix, Cabal, parsec, haskell-src, network, QuickCheck, HUnit, mtl, fgl, X11, HGL, stm, readline, (lang), (concurrent), (posix), (util), (data), (text), (net), (hssource) (are the ones in parentheses deprecated? (from ghc-pkg -l output))
I would say there is no need to do that, since we can just depend on ghc and get the right thing, like we do now.
But shouldn't the tool to make debs from cabal packages automatically build-dep on things the cabal package says it needs? Doing the above would mean we don't need to special case it for that list.
My opinion is I shouldn't do the split+rename, but should provide everything not in parentheses (although I'm not sure about rts).
I don't think you really need to. A Provide is only useful if there are several ways to satisfy a dependency, which there really aren't here.
This would also mean things would keep on working if (in at least one case, when) bits get split out from ghc6 into their own package.
Thanks Ian
On Tue, Mar 15, 2005 at 09:24:09PM +0000, Ian Lynagh wrote:
I would say there is no need to do that, since we can just depend on ghc and get the right thing, like we do now.
But shouldn't the tool to make debs from cabal packages automatically build-dep on things the cabal package says it needs? Doing the above would mean we don't need to special case it for that list.
Well, my tool doesn't automatically build-dep on anything; the user still has to craft debian/control like usual. No idea if anyone else has a tool...
I don't think you really need to. A Provide is only useful if there are several ways to satisfy a dependency, which there really aren't here.
This would also mean things would keep on working if (in at least one case, when) bits get split out from ghc6 into their own package.
Assuming people build-dep on the provided packages now, but really, I'm not sure that there's any call to split most of those out. I could see a ghc and a ghc-nox, I guess.
-- John
On Tue, 15 Mar 2005, John Goerzen wrote:
But shouldn't the tool to make debs from cabal packages automatically build-dep on things the cabal package says it needs? Doing the above would mean we don't need to special case it for that list.
Well, my tool doesn't automatically build-dep on anything; the user still has to craft debian/control like usual. No idea if anyone else has a tool...
One could imagine an improved or alternate tool being constructed in future, though. Doing this now will make life easier in future if such a thing emerges.
I don't think you really need to. A Provide is only useful if there are several ways to satisfy a dependency, which there really aren't here.
This would also mean things would keep on working if (in at least one case, when) bits get split out from ghc6 into their own package.
Assuming people build-dep on the provided packages now, but really, I'm not sure that there's any call to split most of those out. I could see a ghc and a ghc-nox, I guess.
I would be in favour of adding the provides now so that the flexibility to split things out in future is there.
Cheers,
Ganesh
On Mon, Mar 14, 2005 at 09:54:20PM +0000, Ian Lynagh wrote:
"Provide: libghc6-OpenGL-dev, libghc6-GLUT-dev"?
(oops, should be lowercased)
Should the ghc6 package provide libghc6-$foo-dev for each of the following?: rts, base, haskell98, template-haskell, unix, Cabal, parsec, haskell-src, network, QuickCheck, HUnit, mtl, fgl, X11, HGL, stm, readline, (lang), (concurrent), (posix), (util), (data), (text), (net), (hssource)
The conclusion, partly from IRC, was (tell me if I've got anything wrong): * No package renames/splits need to be done. * The parenthesised packages are "hidden", but correspond to the deprecated hslibs packages so shouldn't be provided. * The others should be provided. Thus hugs and nhc98 should also be providing lib{hugs,nhc98}-$foo-dev for any packages they ship with.
Something I've just thought of - I'm not sure if hugs and nhc98 provide all the modules ghc does for each package they have. If this is the case then I'm not sure what a good solution is.
At some point we're also going to have to decide whether profiling libraries go in the same package or in a -prof package.
I think we need to allow for profiling modules to be split off, or ghc6-prof will need to be merged back into ghc6. So barring objections I'll provide libghc6-$foo-prof appropriately and update policy accordingly. If we decide to drop these names in the future then no harm is done by removing them later.
Thanks Ian
debian-haskell@lists.urchin.earth.li
-
Ganesh Sittampalam -
Ian Lynagh -
John Goerzen