[arch-haskell] The ArchHaskell project needs your help

[Peter Simons]

Hi guys,

there are 3 (more or less) separate efforts going on that are loosely organized
under term "ArchHaskell":

 1) the ArchLinux library,

 2) the cabal2arch utility, and

 3) the habs repository of PKGBUILD files.

In the last couple of months, the ArchLinux library has been developed mostly
by Remy; the cabal2arch utility has been developed mostly by Magnus; and the
habs tree has been maintained mostly by me. Since these projects are built on
top of each other, the 3 of us have used this mailing list to coordinate our
efforts.

Now, these projects do stand on their own, but they are not ends in themselves.
Rather, these projects are means to achieve another, greater goal. That goal is
to provide comprehensive and up-to-date build instructions for ArchLinux that
allow everyday users of the distribution to install all Haskell packages
registered on Hackage through the native package manager (as opposed to
installing them with cabal-install, which is always possible, of course, but
requires some minimal knowledge about Haskell).

The current state of affairs can be summarized as follows:

 * Hackage features 2,715 distinct packages.

 * Our habs tree -- which roughly corresponds to the set of packages published
   on AUR -- has 1,990 distinct packages, meaning that we support approximately
   73% of Hackage.

 * Of those 1,990 packages that we publish, 578 are known to have version
   conflicts within the package set. If anyone would try to install all those
   1,990 packages on his or her system, then *at least* 578 packages would fail
   to compile. The actual number of build failures would clearly be higher than
   that, but we don't know what exactly it is, because we don't have a way to
   measure that number. If we stick to the lower limit of 578, then it's fair
   to say that at least 29% of the PKGBUILDs that we publish are broken in one
   way or another.

 * For 301 out of the 1,990 packages that we publish, updates are available on
   Hackage that we haven't processed, which means that approximately 15% of the
   packages that we publish are out-of-date.

If our goal is to provide comprehensive and up-to-date build instructions that
bring Hackage to ArchLinux, then one may wonder how successful we have been. We
cannot quantify "success" in objective terms, but the known facts allow for
some approximation. We provide PKGBUILDs for 73% of Hackage, of which 29% don't
compile and 15% are out-of-date. Let's assume that about half of the packages
that don't compile are outdated, too. From

                                 301
                    1990 - 578 - ---
                                  2
                    -----------------  = 0.4646408839779005
                          2715

it follows that we have succeeded at providing reliable and up-to-date build
instructions for approximately 46% of Hackage. Personally, I feel that's quite
alright considering how scarce our resources are.

>From an ArchLinux user's point of view, however, that number looks a little
different. If you are an average ArchLinux user who is trying to install the
latest version of a random Haskell package from AUR, then that attempt is more
likely to fail than it is to succeed.

Of course, the accuracy of that estimate can be debated. One might argue that
some packages are more important than others, and that the important packages
are more likely to build than the ones that no-one needs anyway. One might
argue that users have all kinds of mechanisms available to them to work around
those problems, and so on. But those technicalities are not going to change the
fact that we do clearly not achieve our greater goal of bringing Hackage to
ArchLinux in way that lives up to the motto of "batteries included", which is
the Haskell community's way of saying "our stuff just works". As far as
ArchHaskell is concerned, it does not.

Now, there are major challenges ahead. We need to improve the quality of our
package set. On top of that, switching to GHC 7 is going to be a lot of fun.
The prospect of dynamically linked binaries forces us to re-think the way we
determine what the difference between $depends and $makedepends is. The
continued growth of Hackage is going to push the limits of our tool-chain even
further. All of this needs to be addressed in some way, and everyone who has an
interest in this effort is hereby encouraged to contribute his or hers ideas
and suggestions now.

To get the discussion started, I'd like to offer a concrete question that you
might want to think about: is it realistic to try and support *all* of Hackage?

Take care,
Peter