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

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. 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