On Fri, 2005-12-09 at 09:55 +0000, Simon Peyton-Jones wrote:

| I think that's because we track dependencies on libraries but not | executables. So having one lib per package allows us to track library | deps correctly. | | Having more than one library in a package breaks dependency checking as | described in the wiki page.

Crumbs. What is "a library"?

A quick clarification of terminology: With GHC a package is described by an entry in the package.conf database, it usually has just one libHSthing.a file. "base", "haskell98" etc are ghc packages. With Cabal a package is described by a .cabal file. It can contain at most one GHC package (though it is of course not compiler specific) and zero or more executables.

Previously I'd understood that a package *was* a library. I think you are saying that

Shipments contain N packages Packages contain N executables and M libraries

So Cabal packages currently contain N executables and 0 or 1 libraries.

Libraries contain N modules

Do we really need FOUR levels? (Shipments, packages, libraries, modules)

Joe is getting worried.

I'm not sure that we need shipments, just some convenient tools for maintaining a collection of related packages. On the other hand how does one conveniently talk about a "project/system/thing" that has various optional bits. As you said earlier, Joe wants to install "HSQL" but the fact is that there isn't HSQL, there the hsql core bit (which is useless on it's own) and backends for various databases. So if we've just got packages then Joe has to know to install hsql and hsql-postgres or whatever. Some Linux distros have the notion of a meta-package that ties together a collection of packages that may have some optional dependencies. Duncan