This is an attempt to summarize and separate the problems, in the way I see them: There are two things that are too complicated right now: [1] A library writer needs clear instructions what he can do with his library to package it in a standardized way usable with as many Haskell systems as possible. [2] A library user needs a normalized way to install additional libraries into his Haskell system(s) and keep them up-to-date. The following factors make both problems hard to solve: [A] There are multiple Haskell "compilers" out there, with very different properties. They support a different number of extensions, have different command line flags, one isn't even a compiler ;-) Furthemore, they have their own package systems which are incompatible. [B] Different versions of the same compiler are binary-incompatible. So on a compiler upgrade, the user will either need to reinstall libraries completely or at least do something to recompile the libraries. The current approach, as mentioned before, is to make the set of standard libraries increasingly large. I agree that this is not a really good solution, because compile times increase, the users may get huge sets of libraries they don't really need, and they may get them multiple times. A project that works that way, for example, is KDE. It is quite hard to upgrade single packages without upgrading the entire Desktop environment plus libraries. There, I don't find that situation ideal, and still, KDE is at least centrally organized and has global releases. The Haskell compilers are all separate and should stay that way. The situation as it is almost completely rules out binary-only versions of libraries. I will thus try to focus on source based libraries from now on. I vote for a two-level approach: I. Define a clear and precise way how and where a Haskell library has to be installed on a system. This installation should be as compiler-independent as possible. The files should go in a central place, and there should be additional information at that location of the kind that is now for example stored in GHC's package configuration file. As far as a library does not depend on a particular Haskell compiler (for example, it needs C libraries as well), these C libraries may well aready be built and installed. But the Haskell code should be installed in source form. Authors of libraries should find these guidlines in a clear and easy to understand form somewhere on the web, and there should be tool support to facilitate conforming to the standard. I'd go for some well-documented Makefile includes, but if nicely written, a Haskell based system may also work. But I think, the system and language here is secondary, as long as it is clear _what_ needs to be done ... II. Each Haskell compiler should be extended with a tool that can take a library from the standardized source based install described in I. This tool could be similar in interface to ghc-pkg, but should not only collect package configuration information, but also _build_ the Haskell code for the compiler and create and install libraries to the right positions as necessary. The tool should provide a way to _add_, to _remove_, and to _completely regenerate_ libraries. Additionaly, there needs to be one single tool, that levels the potential differences between the package tools of the Haskell compilers and keeps track of all the compilers installed in a system. Let's call it "global package manager". The last thing that would be called in the Makefile (or whatever) that is supplied with a library is the global package manager with the option "add" and the library name. The global package manager would look in the standardized central place for the library, find out for which of the installed Haskell compilers it works, and call their respective package managers that will the build and add the library individually. The last thing that would be called in the Makefile (or whatever) of a Haskell compiler would be its own package manager with the option to regenerate all libraries. Because they are installed in a place independent of the compiler itself, they will survive a compiler upgrade and can automatically be rebuilt for the new version. For hugs rebuilding would be nearly trivial, for GHC is might take a long time, but that's life. Summary of the proposal: * Define a clear standard to install Haskell libraries on a system in a way that is independent of a specific Haskell compiler (both type and version). * Support library writers by tools to make sure they can conform easily to that standard. This includes a global package manager that can be called in the end to pass responsibility over the library to the compilers installed on the system. * For each Haskell compiler, write a/modify the package manager so that it can handle the addition, removal, and complete regeneration of such source-based installed libraries. [1] This will make the situation easier for package writers, because they do not have to care about actually _building_ the library for a specific compiler or compiler version. They will only have to conform to a specific installation format, and that will be supported by tools. [2] This makes life easier for the users, because they can just install additional libraries and "never" have to worry about them again. If they install additional Haskell compilers or upgrade to newer compiler versions, the libraries will always automatically become available. Of course I realize that I probably have forgotten many things and that I may not have made myself clear at all points. So you're all invited to tear this proposal apart! Best, Andres -- Andres Loeh, Universiteit Utrecht mailto:andres@cs.uu.nl mailto:mail@andres-loeh.de http://www.andres-loeh.de