[packagekit] Haskell packages

[Duncan Coutts]

Hi everyone,

In the Haskell community we've been working hard over the past couple
years to make it easier to build and distribute our cool software. We
made a build tool much like autoconf/automake but for Haskell packages. 

This tool is called Cabal:
http://www.haskell.org/cabal/

Cabal packages also have metadata with all the usual stuff, like name,
version and dependencies etc. There is a standard command line interface
to configure, build and install a package.

We have an ever growing collection of packages in our online repository:
http://hackage.haskell.org/

One goal of this system was to make it easier to build distro packages.
Several teams have made tools to translate Cabal packages into native
distro packages. There are such translators for rpm, ebuild, deb and
something for windows .msi too.

We've done pretty well, there are an increasing number of Haskell
libraries and tools in major distros.

However the number that are included in distros is always going to be a
subset of the number available in the HackageDB collection. I package
Haskell stuff for Gentoo and I know personally that we only add packages
that we think are of general relevance and are stable etc. We do have QA
standards :-). So the point is, there will always be a large number of
packages that are not available via the system package manager. We need
some way to co-exist.

Because we do not expect to have all packages available via the system
package manager we have also created our own mini-package manager tool.
It downloads builds and installs packages and their dependencies. We are
currently mainly targeting per-user installs with this tool. It can do
global installs too. Of course our users would prefer that it satisfy as
many dependencies as possible by delegating to the native package
manager, and only directly installing what is not available natively.
This is obviously a bit tricky.

So there are perhaps two levels where it might make sense to integrate
with PackageKit. One is to make a Cabal backend for PackageKit so users
can have a nice UI to browse and manage installation of Cabal packages.
The other is to get our cabal-install tool to ask PackageKit to install
packages for us, to satisfy dependencies that are available through the
native package manager (these might be Haskell packages or native C libs
for Haskell libs that bind C libs).

So my question is how realistic does this seem? Could PackageKit work
with a primary and secondary package manager? From a UI pov it might
make sense to present secondary package managers as just different
repositories. Of course, all this assumes that the secondary package
manger behaves properly and doesn't tread on the toes of the primary one
(like installing into /usr/local).

>From a UI pov, package overlaps don't seem to hard, it's the same
problem as having different repos. The problem is what to do when a
secondary package needs a primary package.

Anyway, interesting to ponder.

-- 
Duncan Coutts : Gentoo Developer (Haskell team)