Cabal interface changes proposal

[Duncan Coutts]

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