Andres Loeh
[big snip] 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. [big snip]
I don't think this is so. It is certainly true that:
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.
But I don't see this as a problem. The major package systems already support version dependencies which can express ideas like: package foo for ghc-5.04.2 version == 2.1 depends on package ghc version == 5.04.2 package bar for ghc-5.04.2 version >= 1.3 People maintaining packages (e.g., the person who maintains all the Hugs packages on Debian) decide which versions of the compiler they wish to support and provide binary packages for all the libraries for all the compilers they support. After building a small amount of infrastructure to set up these multi-way builds, the only additional burden from doing this is the need for more disk space and more processing time. The only issue I see is coming up with a package naming scheme which lets us distinguish 8 different versions of each library. I prefer binary releases to source releases for Haskell libraries because building libraries can lead you into a lot of complexity when things don't work as planned and it'd be better to put that burden on a small number of people. (Of course, systems like FreeBSD which rely on source packages are great and those systems should use source versions of Haskell libraries - they're just not for everyone.) -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/