Simon PJ writes:

What we want, I think, is an aggregation mechanism. In particular

there could be one or more "contrib" packages, optionally hosted at fptools/libraries, containing code contributed and maintained by different folk, but packaged and distributed by one person, a Contrib Builder (better titles welcome)

Actually, I think we need multiple contrib builders just as there are for GHC at the moment. Specifically: - we need someone who knows about and cares about FreeBSD to produce freebsd ports of libraries - we need someone who knows about and cares about Windows to produce .msi packages - we need someone who knows about and cares about Debian to produce debian packages and so on for each format we want releases in. It's unlikely that one person will have experience of all the different systems we want releases for so it has to be multiple people. For any one format, it may be easier to have one person do all packages for all compilers and all libraries or it may be easier to split the task by compiler, by software license, by repository, or whatever. (Obviously, using a common infrastructure makes it easier for one person to handle more libraries and more compilers.) Simon also says:

The Contrib Builder will probably want to do automated nightly build/test runs of the package.

I think this suggestion blurs the distinction between library writers and contrib builders. It is a library writer's responsibility to deal with bugs - they would probably benefit hugely from this sort of infrastructure. Contrib builders should only be dealing with bugs they have introduced in a particular package or, arguably, with portability issues. The way I see it, there should be a very clearly defined interface between library writers and contrib builders. Library writers should provide version numbered releases (absolutely _not_ daily CVS snapshots) together with certain metadata (documentation, which version number this is, which particular versions of other libraries the library works with, etc.). Contrib builders apply some patches to customize it for a particular system (debian, freebsd, etc.), compiles it, runs the testsuite, builds the documentation and packages it up. Contrib builders might also act as a conduit for bug reports. -- Alastair Reid ps The above assumes that we want binary packages (I think there's plenty of evidence (Redhat, Debian, etc.) that this is what people want to use). It assumes that we want to work with the 'native' package mechanism on a system rather than providing our own parallel mechanism. It assumes that authors aren't always able to update their library whenever there is a significant change in one of the things they depend on: the nightly tests fail every night for a month before they get dealt with. Finally, it assumes that most people want official releases of code that the author feels are in a usable state rather than random snaphots of an evolving system.

"Simon Peyton-Jones" wrote,

These both raise a common question: how can someone distribute a library? (This is a different question to the library-infrastructure question about how to build a library, which we've been discussing recently.) [..] OK so that's the idea.

1. Does it seem like a reasonable idea?

2. There is a pressing need for the first Contrib Builder for libraries like Dominic's crypto and Koen's Chunk library. Any volunteers? Even for one implementation target?

Languages like Perl and Python face the similar problems as we do, although they have less language implementations to worry about (at least for Python, there is more than one implementation). So, the question is whether we can't more or less follow their lead. Perl is certainly extremely successful at establishing itself by way of a flourishing libraries community. I don't know many details of how the Perl community works, but here are what seem to be core points: * Well-known central repository: CPAN http://www.cpan.org/ * Binary distributions of library packages can be obtained independent of the main system. CPAN has something called Perl Ports. On my RedHat 8.0 system, grepping for Perl packages leads to the appended result. To facilitate this, it would probably be worthwhile to have some infrastructure that makes it easy for a library author to make a new library portable across operating systems and Haskell implementations (and their associated build and package systems). If this were really simple, we might not need to agglomerate unrelated libraries into random contrib packages. I don't really have much of a concrete idea of how such an infrastructure should look like, but maybe somebody else has. Cheers, Manuel -=- AttitudeAdjuster chak 608 (~): rpm -qa |grep perl perl-Storable-1.0.14-15 perl-DateManip-5.40-27 perl-XML-Dumper-0.4-22 perl-Inline-0.43-7 perl-5.8.0-55 perl-SGMLSpm-1.03ii-6 perl-libwww-perl-5.65-2 groff-perl-1.18-6 perl-suidperl-5.8.0-55 openssl-perl-0.9.6b-33 perl-Filter-1.28-9 perl-HTML-Parser-3.26-14 perl-XML-Parser-2.31-12 perl-libxml-enno-1.02-25 gimp-perl-1.2.3-9 perl-Parse-Yapp-1.05-26 perl-libxml-perl-0.07-25 perl-XML-Grove-0.46alpha-21 perl-PDL-2.3.2-10 perl-URI-1.21-3 perl-XML-Twig-3.05-3 perl-CGI-2.81-55 perl-CPAN-1.61-55 perl-HTML-Tagset-3.03-25 perl-XML-Encoding-1.01-20 perl-DB_File-1.804-55