Sorry I haven't gotten around to replying to everyone's comments.
I've been shifting apartments :)
"Simon Marlow"
I think the proposal is great.
Thanks!
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).
Good point. Thanks.
FreeBSD's ports is both a source and binary package system. A FreeBSD system functions perfectly well using only binary packages.
I see. Can you give me a light summary of what a binary package for BSD looks like? Do people distribute binary packages on their web sites?
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 -
I think I made it clear in the next paragraph that this is still a problem in FreeBSD, but I'm only suggesting that the end user actually has a reasonable _solution_ for a source distribution. In a binary distribution, the user either has to download the source (package) and recompile themselves, or wait for the maintainer to do it. However, your point about FreeBSD having binary packages may make all of that false.
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.
In fact, I was recently thinking that binary distributions like Debian should have some support for a recompilation: a package should be able to declare that it has this special "recompile" dependency on ghc / nhc / xemacs / gnuEmacs, and when a new version of the compiler is uploaded to the autobuilders, they should go out and recompile all the packages. Instead, Lisp, Elisp, and Haskell all have to roll their own solutions for roughly the same problem.
./Setup.lhs bdist: wouldn't it be better to create a source RPM than a binary RPM?
That's a good point.
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.
That is what the prototype does for Debian; it creates the skeleton for the user to edit and build the binary distribution from, except that it does actually go ahead and build the binary distribution, for better or worse.
The PackageConfig file: I'd leave out 'provides' and 'isDefault' unless we have a convincing example which needs them.
Actually, I consider the Haskell Implementations themselves to be the best example: we want a way to say that libraries depend on having a Haskell98 (or Haskell04 ;) ) Implementation installed, and we want to be able to track the default Haskell Implementation. Perhaps this should be built into the system, but I think it has more general applicability. For instance, if we had that common GUI API that was discussed at ICFP, and there were several implementations of it (one for Windows, one for Gnome, one for TCL or whatever), then a package could depend on having "something that implements the GUI API", rather than a particular package.
Possibly add: 'haddock_html_root :: String' and 'haddock_interface :: String' for documentation.
I definitely like that idea.
I'm thinking about removing 'extra_ghc_opts' - it's highly dodgy when combined with 'auto'.
I'll remove it from the proposal for now, and I'm going to add this text: I propose that implementation-specific fields be prepended with the implementation name: ghc_interpreter_flags, hugs_interpreter_flags, etc.
I agree with Ross's comments about data vs. code. Let's abstract as much as possible as data.
What did you think about my points in the followup post. I definitely agree that we want to leverage this data, but there are a variety of ways to do it! peace, isaac