Haskell library infrastructure coordinator

[Alastair Reid]

> There should probably be test suites to cover dependencies to ensure
> that all libraries are adequately in sync -- I'm not sure how easy
> this is to do in practice.

Hmmm.
It's best done as the library is being written because it could actually help 
development and because the author likely has a better idea of what a 
function is supposed to do.  But test suites are usually ignored or built 
long after the fact.  Since quickcheck is quite easy to use, I wonder what's 
missing?  Is it infrastructure (a handy driver program and some make targets) 
or some well-worked examples to cut and paste from?  Where do I find examples 
of how to quickly add quickcheck to my library?

> BTW, Debian is unusual, in that updates happen all the time. (There
> are numbered releases, but they aren't commonly used, I think.  They
> manage to make it work pretty well -- better than most others do for
> third party stuff, IMHO.  Perhaps that model can be used?

Debian had some technical advantages in the beginning (better dependency 
annotations) but I understand that redhat and others have now caught up.

But Debian still has a cultural advantage: packages are built, tested, 
debugged, etc. with the intention that people will update and install a 
little bit at a time rather than buying a new set of CDs and updating the 
entire system in one go.  This puts a lot of stress on the dependency 
annotations which keep the system consistent but it also means that problems 
in the dependency annotations rapidly come to light.  (I think it also means 
that the debian testing procedures are more rigorous but don't know for 
sure.)


Debian does use numbered releases though.  Here's a small sample of the 
version numbers installed on the machine I'm using just now:

ii  zip            2.30-5         Archiver for .zip files
ii  zlib1g         1.1.4-11       compression library - runtime
ii  zlib1g-dev     1.1.4-11       compression library - development
ii  zlibc          0.9j-6         Uncompressing C Library

The version numbers are of the form a.b.c.d-p where a.b.c.d is whatever 
version number the authors use and the -p part is the version of the debian 
package.  So, for example, the package for zip version 2.30 has been revised 
5 times (perhaps fixing dependencies, adding documentation, etc.)

But, Debian packages might apply patches to the software which are not 
included in the author's software release.  These might be trivial like 
changing a hardwired path from /usr/local/lib to /usr/lib or they might be 
significant like fixing a known security hole in the Linux kernel.

--
Alastair Reid