2. Issues Facing Developers

There are a number of issues facing developers of Haskell software when they decide to deploy their work.

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)

2.1. Issues Facing Packagers

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.

2.2. Why We Should Solve This