My thoughts on debianisation of haskell packages

I have written a few posts on debianising haskell packages in the past. Back then I stopped looking at it because of the age of the ghc-related packages in Debian Sid. Things have since improved and I’ve finally found some time to revisit the problem. This isn’t however a technical post, but rather a post on the strategy I think would be best for making Debian the best Haskell development environment in the universe.

In my opinion there is no point in trying to get all packages on Hackage into Debian proper. The few Debian developers (DD) who are interested in Haskell and maintain the existing packages are already terribly short on time and adding further burden would improve the chance of timely availability of GHC in the future. Sure, it would be possible to recruit more DDs with an interest in Haskell (I’ve considered in the past to try to become a DD, but the timing was off on both sides and I decided to postpone it) but it would take time. Maintaining 1000 packages is a huge task, and would require quite a large team I think. I suspect the recruiting would be such that if one were to plot the number of packages the team could maintain as it grew over time, compared to the number of packages on Hackage, then the lines would diverge rather than converge ;-)

Instead I think all packages on Hackage should first be debianised and put in a source-only repository. As some packages grow in importance and get added into Debian proper (e.g. a killer-app written in Haskell) then it and its dependencies are removed.

I believe that with this solution it’d be possible to quickly make a large part of Hackage available on Debian while still giving the DDs time to grow the number of “Haskell-friendlies” within Debian.

This of course rests on a few assumptions:

  1. It would require a smaller team to maintain source packages than binary packages. At least it would require less time from DDs.
  2. There is some space to store the source packages, ideally non-Debian space since that would mean even less involvement required by DDs.
  3. There’s a tool available in Debian that makes it easy for end-users to download, compile, and install source packages.
  4. There’s a tool that automates the creation of a Debian source package from a Cabal package.

In my optimism I’ve decided to not worry about the two first points and instead focus on the last two. Besides the optimism they also feel like the points I can actually address on my own, I’ll need help with the first two.

The tool in Debian for handling source packages is apt-src. In my opinion it will suffice, but if the developer would address one issue then it would be perfect.

The tool for automating the creation of Debian source packages could be cabal-debian. It is a very good tool, and it seems to be suited for maintaining Debian packages. I only have two objections to it. The first objection I have is that it is almost too well engineered; it does more than is necessary, e.g. there is no need to maintain proper changelogs in the source repo. The second is that it requires all dependencies of a package to be installed when it’s debianised. It is almost certainly the tool for the team charged with maintaining a large set of Cabal-based packages in Debian proper, but for the source-repo it might be too much. Because of that I’ve started hacking on a simplistic tool that I feel would be better suited for the source-repo.

Jeremy Shaw

The darcs version of cabal-debian no longer requires the dependencies to be installed just to create a debian directory. I’m not sure if I understand the proper changelog complaint. cabal-debian just generates a pretty generic debian/changelog the first time you run it so that you can build the package. What would it do instead?

IMO, if you can create a repository of source debs that actually build, it should not be too hard to also create a binary repository using the autobuilder ( The autobuilder can already download individual source debs from a repository and build them. It would be trivial to download the Sources index and automatically create targets for all the source packages on-the-fly. (the haskell-debian library already provides all the functions for fetching and parsing Sources files). The autobuilder already knows how to track build-dependencies and rebuild packages when build-dependencies change.

I guess the take away is that you shouldn’t have to do anything special to support the autobuilder. Simply creating a working source deb repo should be enough…



Let me know when that version makes onto Hackage, I’ll be interested in checking it out. The changelog comment is simply related to the --update-debianization argument you can pass to cabal-debian. In my mind it won’t be necessary to update the quick-and-dirty source packages. cabal-debian simply does more than what is needed for what I hope to do.

So you are saying that I should take a look at autobuilder rather than spend more time on apt-src? What you say sounds very good.

When will autobuilder be available on Hackage? ;-)

Jeremy Shaw

It should be trivial to make a --replace-debianization that would remove the existing debian directory and create a fresh one. Is that what you are looking for?

The autobuilder is definitely not a replacement for apt-src. It is designed to allow a team of people to maintain one or more debian repositories. It has features like:

  1. the list of packages to be built can be checked into a shared repository
  2. ability to build packages that are stored in many different ways: tla, hg, darcs, tarballs, quilt-patches, Debian source repositories, svn, and more
  3. system/tools for uploading packages to a package server and installing them into a debian repository
  4. detect when packages need to be rebuilt due to build dependency changes or changes to the source.
  5. works with Debian and Ubuntu
  6. packages are built in a clean chroot that is based on what dist the package is being built for
  7. and more…

So, it could be the right tool for maintaining a binary distribution, but it is definitely fills a different niche than apt-src.

Similar to what happened with the cabal-debian stuff, the autobuilder will need to go through a few iterations of cleanup before it is suitable for general purpose use. The biggest stumbling block is that there is very little documentation on how to use it or what the big picture looks like. While it is not hard to use, we have had the luxury of newcomers starting with a working configuration and having easy access to hands on training.

I’ll see if I can get the latest cabal-debian and autobuilder up on hackage tomorrow as a starting point.


@Jeremy, thanks for the clarification on autobuilder.

Leave a comment