Contrib packages

[Alastair Reid]

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.