There are a number of issues facing developers of Haskell software when they decide to deploy their work.
Binary incompatibility between Haskell Implementations and between versions of some implementations make it very difficult to distribute binary libraries: if they are expected to work together, all of the libraries on a user's system need to be built with the same compiler. This makes it a virtual necessity that the source code for a Haskell library be distributed to the end user of that library, although other options exist for systems like Debian (Section A.1) which have auto-builders.
Compilation is difficult: It was noted above that it is usually necessary to distribute the source code for Haskell tools to the end user. The end user has to compile each Haskell tool they use, but the task of compilation is complicated by a plethora of preprocessors (such as arrowp and greencard) and interfaces with non-Haskell libraries (such as Java, X, C, and GTK). Further, there is no way to formally express dependencies between Haskell tools, so the users have to visit the home pages of the projects they're interested in and find the dependencies.
The Haskell Implementations are not completely compatible either: They support different extensions, different libraries, different binary formats, different flags, and different packaging systems.
Given that compilation is difficult in and of itself, it is further complicated by a wide variety of target platforms that it is desirable to support. These systems may treat files differently (copying of files, path names) or have different defaults for where to put compiled files or source code to make them available to the user. The variety of Haskell Implementations and target platforms make writing of a generic build system that "just works" very difficult.
Having managed to compile and install all of the Haskell software they need, if a user installs a new compiler (or version thereof), all this work needs to be redone. All of the libraries on the system will have to be recompiled to match the version of that compiler (this is apparently a bigger problem with GHC than with NHC, and not much of a problem with Hugs.)
Compare this to the experience of installing a typical library or tool written in C or C++ on a Debian GNU/Linux system: The user consults a database of known programs (which is stored on her computer) and runs a single command to install that package. The package management tool figures out the dependencies, downloads all dependencies downloads the package, and installs them in the proper order. The packages are already compiled by a set of central servers. In fact, there is no reason that this kind of interface can't be available to the end user except for the difficulty of creating binary packages. (See Section 2.1)
There are roughly speaking, three different kinds of operating-system package systems: source distributions (FreeBSD, Gentoo), binary distributions (Debian, RPM), and language-specific distributions (CPAN, XEmacs). What we are proposing to create is a language-specific distribution that assists in the creation of both source and binary packages for other operating systems.
As mentioned above, it is possible to create an operating system package for a Haskell library. Indeed, its no harder to create a Haskell package than any other kind of package; Haskell packages are harder to maintain, however. For instance, in the Debian GNU/Linux system (Section A.1), which is a binary distribution, there is currently no way to express that a library needs to be recompiled when a new compiler is uploaded to the autobuilders. Currently, the only solution is to re-upload library packages to the autobuilders at the same time you upload a new Haskell Implementation. Similarly for Redhat, binary packages have to include the version number for GHC that they were compiled with.
In a source distribution like FreeBSD (Section A.4), this isn't a problem, since the end user compiles all of their software themselves. However, when the end user compiles and installs a new Haskell Implementation, all of the libraries compiled with the old Haskell Implementation will no longer work and need to be recompiled. As I understand it, there is currently no means of performing this operation automatically.
Emacs / XEmacs presents packagers with some of the same issues; they are both, practically speaking, Lisp compilers, and incompatible, much like different versions of Haskell Implementations. When an elisp package is installed on Debian, it gets compiled automatically (on the end user's machine) for each version of Emacs / XEmacs that is installed. This procedure is orthogonal to the XEmacs Packaging System (Section A.5) and is a duplication of effort in some cases, but that is really the only way to make it work with Debian. This has some ugly properties from Debian's standpoint: once compiled, there are files in the operating system that the packaging system doesn't know about. These are similar to issues that Haskell packagers for Debian will have to face.
We need to evolve a decentralized way of distributing libraries. The current model of distributing them with the Haskell Implementations puts too much strain upon the Haskell Implementation authors, and is not sustainable in the long-term. If this continues, availability and reliability of libraries will suffer, and Haskell itself will suffer in the long-term as a rich set of libraries is becoming the standard for successful programming languages.
If we can help operating system packagers build packages (Debian, RPM, etc.), then we'll have more happy end users.
If we lower the cost of evaluating Haskell and Haskell tools, more people might try them out.
Many Haskell programs are developed as research prototypes and abandoned. The subsequent bitrot makes it difficult for the community to take over the projects. Formally specifying versioned dependencies and creating a central repository for Haskell tools can help solve this problem.
Active participation with the rest of the Free Software community (inclusion of Haskell in OS distributions, interoperability between Haskell tools and external libraries) can bring attention to Haskell and perhaps bring more talented developers into The Flock.