Library Infrastructure Proposal & Home Page

[Simon Marlow]

I think the proposal is great.  Here's some random comments:

It might be worth saying earlier on that the library infrastructure is
expected to be a layer underneath the platform's native package support
(if such support exists).  For example, I've never used Python's
Distutils, but I have a bunch of Python packages on my system that were
installed using the native package system on top of Distutils (I
presume).

FreeBSD's ports is both a source and binary package system.  A FreeBSD
system functions perfectly well using only binary packages.  To a
certain extent Gentoo is the same, although they place far less emphasis
on binary packages.

FreeBSD (in source or binary mode), and Gentoo, have no support for
recompiling packages when something they depend on has changed.  This is
the biggest failing of these systems IMHO.  The 3rd paragraph of 2.1
therefore isn't correct - there's still a big problem for source-based
distributions. However, this is not *our* problem, it's theirs - when a
dependency is updated, everything that depends on it should be
recompiled.

./Setup.lhs bdist:  wouldn't it be better to create a source RPM than a
binary RPM?  Once you have a source RPM the RPM tools can be used to
build a binary RPM.  Similarly for FreeBSD and Gentoo - I'd expect
Setup.lhs to produce a port skeleton/ebuild for me, not a binary
package.

The PackageConfig file:  I'd leave out 'provides' and 'isDefault' unless
we have a convincing example which needs them.  Possibly add:
'haddock_html_root :: String' and 'haddock_interface :: String' for
documentation.  I'm thinking about removing 'extra_ghc_opts' - it's
highly dodgy when combined with 'auto'.

I agree with Ross's comments about data vs. code.  Let's abstract as
much as possible as data.

Cheers,
	Simon