Shipments in Cabal

[Duncan Coutts]

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