debian-haskell March 2005

debian-haskell@lists.urchin.earth.li

5 participants
4 discussions

GHC sarge strategy?
by Isaac Jones 29 Mar '05

29 Mar '05

Heya. Sorry if this was answered in the other thread, but what's your basic strategy with getting the new GHC into sarge and sid? I figure at least it could go into sid with an RC don't-move-to-sarge bug. At least then Hugs and GHC in sid would match up without the danger of a bad ghc going into sarge. Does it make sense for anything that depends on cabal (like haskell-devscripts) to depend on cabal OR ghc 6.4, even though 6.4 isn't in debian yet? It would make my life eaiser :) peace, isaac

3 7

ghc, nhc and sarge
by Ian Lynagh 17 Mar '05

17 Mar '05

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

3 5

Local libraries for hugs?
by Simon Guest 10 Mar '05

10 Mar '05

Hi, I want to install a library (FMP, Functional Metapost, IIRC), for hugs. The hugs README.Debian mentions + Haskell source files for locally installed public extension modules should be installed in /usr/local/share/hugs98/extensions . Binary shared objects included in extension modules should be installed in /usr/local/lib/hugs98/extensions and symlinked from there to /usr/local/share/hugs98/extensions . However, I don't quite see that what I have is an extension module. It's just a library that I want the user to be able to import by doing, for instance, import FMP. So where should I put it so that it's visible to local users without having to play games with HUGSFLAGS and -P ? Any suggestions? cheers, Simon

1 0

ghc 6.4 prerelease unstable debs
by Ian Lynagh 07 Mar '05

07 Mar '05

Hi all, You can now get i386 unstable GHC 6.4 prerelease debs from Haskell Unsafe. For details on Haskell Unsafe, please see http://haskell-unsafe.alioth.debian.org/haskell-unsafe.html Thanks Ian

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

debian-haskell March 2005