On Fri, Nov 24, 2006 at 05:35:31PM +0000, Simon Peyton-Jones wrote:
http://hackage.haskell.org/trac/ghc/wiki/PackageReorg
I'd be interested to know whether the proposal has general support; what goals are omitted; and what other details are omitted. I'm sure there are many, because this is a complex issue.
I'd like to see some rationale for why each of the core packages have been chosen. I'd have base, haskell98, Cabal, filepath with the rationale that it is likely that people will want to write Setup.hs with them (haskell98 is debatable here, but could probably be argued in on the grounds that it's needed for lots of books/tutorials/... to work). I can't really think of any rationale for any others. For userfriendliness we can have a cabal package called usefulstuff that depends on mtl, regex, ..., but I don't see any need to bundle them all with the compiler. The less we force the implementations to come with, the quicker compilation will be when developing, the smaller Debian packages (for example) can be, the lower the disk space requirements to build GHC, the lower the time wasted when a Debian package (for example) build fails and the fewer packages we are tangling up with compiler release schedules (OK, they can be upgraded independently, but it causes headaches for package-management systems). On quickcheck, the testsuite and GHC: we can have GHC compile any libraries that are put in libraries/ and make ./darcs-all --get-dev grab quickcheck too. On the other hand, you might want to run the testsuite automatically when building debs/rpms/... but personally I'd prefer to use a copy of QC compiled and installed under the testsuite tree for that. This way we wouldn't suffer from the disadvantages above. We don't need the testsuite programs to work after GHC has been installed so we don't have to worry about providing the QC dynamic libraries in the future. Thanks Ian