Shipments in Cabal

Isaac Jones ijones at
Fri Dec 9 14:50:03 EST 2005

"Simon Marlow" <simonmar at> writes:

> I just made some changes to my proposal:
> Mainly I made it so that the sub-packages don't have to be in a
> subdirectory, this means it will be easier to tar up the aggregate
> package.

Can you clarify the terminology a bit?  A distro package is an OS
package?  Like RPM?  And a distributable is a kind of meta-package
that does nothing but depend on other packages?  (If so, let's call it
a meta-package or something).

I can't edit the wiki right now :(

I like the idea of having a meta package that can be only
dependencies, but I don't think I really like the --local idea.  I
don't really like the idea of one cabal package going to build another
package, invoking another setup script.  I think that should be left
for layered tools.

Although I'm all for adding flags to cabal to allow packages to be
used in-place more effectively, I'd rather have a tool where I can

cabal-install: metapackage/metapackage.cabal --searchpath=.

and maybe

cabal-sdist metapackage/metapackage.cabal --searchpath=.

will go and build .tar.gz files for everything it can find.  That way
hackage won't have to change, it still works on the cabal-package

Incidentally, we would need to separate the concept of depends and
build-depends again, I guess.  Remember that all build-depends cause
-package flags to be added to the command line of GHC.  If these
dependencies are executables, then that's bad.

Krasimir, would meta-packages and cabal-install solve the problems w/
visual studio?  We could add flags to cabal to improve in-place usage,
and to do something w/ a particular packageDB (though I want to figure
out a way to solve this for Hugs too).

We could have meta-packages which are just a minor refactoring of
packages to say that they can just depend on other packages.  This is
definitely something that cabal needs anyway.  We clean up the
multi-executable thing, which never worked well anyway.

But the actual handling of meta-packages should be left to layered
tools like cabal-install.  Cabal-get should be refactored to work on
top of cabal-install; cabal-get should just download the packages and
invoke cabal-install to do the dirty work.

The nice thing about this solution is that if we need to add a
shipment: field or some of these other suggestions, we can do it
later and everything will still make sense.

What do you guys think?



More information about the Libraries mailing list