On Mon, 2004-11-22 at 10:40 +0000, Simon Marlow wrote:
First of all, I should say that I doing see an urgent need for this. Packaging systems such as Debian, *BSD & Gentoo manage dependencies and can build multiple packages in the right order just fine, and have support for "collection" packages (eg. installing "kde" causes a bunch of sub-packages to be installed). Introducing this functionality in Cabal would be redundant on these systems. My feeling has always been that we shouldn't duplicate functinoality that is available in a good package system.
Given that, if you really want to do this, then here are my thoughts: basically it would mean introducing another "layer" of packaging, albeit one that lives only at the Cabal level, which Haskell compilers know nothing of.
Here are some issues that initially spring to mind:
- Packages in this layer should be called something other than packages, to avoid confusion (I'll call them shipments, for now).
- Should the shipment have a name of its own?
- Should it have a version?
- Presumably the packages in a shipment depend on each other. That means we need to "temporarily" install packages so we can build against them. This isn't something that the current package proposal really supports, but I think it would be useful.
For example the gtk2hs "shipment" currently builds and registers between 2 and 5 packages (depending on whether optional dependencies are met). We give the overall shipment a name and version but the individual packages have no independent version (ie always the same version as the shipment). The packages in the shipment do indeed depend on each other (gtk and gconf depends on glib, the other packages depend on gtk) so we do temporarily register the packages (currently using a local package.conf file that lives in the build tree). In fact it is important that the local package database live in the build tree since we do not want to install any package until all of them have been built successfully. This localpackage.conf trick is a common one. I know c2hs (and buddha if I recall correctly) does this too. At the distro packaging level different systems do it differently. For a source distro like Gentoo or probably the *BSD ports systems we make gtk2hs a single 'distro package' which has optional deps on other packages (C libraries). On binary RPM systems like Fedora, we put each Haskell (ghc) package in it's own rpm. They each follow the name of the gtk2hs version (they are not independently versioned) but have different external dependencies (on C libraries). Even in the rpm case we have one and one .spec file that generates a handful of binary rpm files. I'm not suggesting cabal must replicate existing behaviour, just documenting some examples to think about. Duncan