Greetings, There has been a lot of discussion recently on the Haskell mailing lists about the best ways to package Haskell libraries and tools for Debian. The main issues are:
1) there are a variety of "compiler" implementations, one of which is an interpreter :) 2) not all Haskell implementations are available on all architectures (ghc for instance) 3) just about every Haskell "compiler" and release is binary-incompatible, (except maybe for nhc98). That is, we'd need different binaries for ghc4, ghc5, and ghc6. Also we'd need different binaries for profiling versions of the libraries, etc. For instance, if I were to package HUnit, which is a simple case since its pure Haskell code, I would need: hunit-{hugs,nhc98} hunit-ghc{4,5,6} hunit-ghc{4,5,6}-prof And whenever a new version of GHC6 is uploaded (for instance), all of the packages like hunit-ghc6 would need to be updated at the same time. That doesn't even get into the issues of the wide variety of preprocessors that are common in this rapidly advancing language[1]. In practice, though, some packages might just be used on the newer compilers. This is why there aren't too many Haskell libraries in Debian right now. We're discussing a set of software tools that might make this situation easier for packagers either by helping to create packages for each version of the compiler, or by building the packages on the user's system. How would Debian prefer to see this? Some people tell me that it'll probably be too slow to build the packages on the end-user's system (as is done for elisp), but I think it would be hard for package maintainers to keep track of so many versions of their libraries. I'm leaning toward writing software tools to help package maintainers build & maintain that large number of packages, but would this be too many Debian packages? peace, isaac [1] Haskell is designed to have a "stable" version, Haskell98, and the compilers come with a variety of extensions so that it is very useful as a research language as well.