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