> This dependency on libreadline4-dev seems to be a special case of a > more general issue, namely how to handle packages in the GHC sense > in the Debian packaging system. The way Perl module code is > packaged for Debian seems to be quite sophisticated: Perl packages > tend to correspond to individual Debian packages, so if a Perl > program packaged for Debian uses a certain module, only that module > (roughly speaking) needs to be installed, and will be automatically. > Ideally, GHC packages would be handled in a similar way, but is it > worth the trouble?
My personal inclination would be to do as Perl does: have many Debian packages with just one or two GHC packages each plus one or more dummy packages corresponding to top level directories in the hslibs tree. One potential problem with this is that GHC packages have unusually strong connections with each other. The problem is that GHC does a lot of cross-module inlining so if GHC package A imports GHC package B then the compiled form of A (i.e., the Debian package) will depend not on B but on the particular version of B that it was compiled against (and the version of GHC used to compile A and B). Changes to B which leave the API and semantics unchanged might still break A. One could get round this in the Debian package by requiring particular version numbers in the packages (it's more usual for a Debian package to depend on ranges of version numbers such as >= 3.2.1) - at the cost of making the restrictions on source distributions a bit stronger then they have to be. Note that there's really no way to avoid this problem: tomorrow some Haskell hacker could come along with a cool Haskell library that they don't want to add to the hslibs collection but which they want to release as a Debian package. They'll be faced with exactly this problem. (This problem may already exist: are there separate packages for the BSD and GPL'd parts of the hslibs tree.) -- Alastair Reid [EMAIL PROTECTED] http://www.cs.utah.edu/~reid/ _______________________________________________ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
