Ideas for library infrastructure

[Alastair Reid]

Andres Loeh <andres@cs.uu.nl> writes:
> [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/