Re: [Caml-list] build tools - good vs. fast, both cheap

[Blair Zajac <blair@orcaware.com>]

William Lovas wrote:
> 
> This is essentially the goal of the GODIVA project (formerly GODOR) that
> Owen Gunden and i are working on:  We're grafting a sensible specification
> onto the frontend of GODI so that it's easier for developers to make
> packages.  In the future, this specification could stay around if some
> other underlying backend technology supplanted GODI, and all that would
> require updating would be the backend of GODIVA.
> 
> A (very!) preliminary release of GODIVA is available as the GODI package
> called godor.  In a few days, Owen and i will be packaging up a new release
> incorporating the ideas from this paper:
> 
>     http://projects.phauna.org/godiva/papers/godiva.ps
>     http://projects.phauna.org/godiva/papers/godiva.pdf
> 
> (And this time, "a few days" really means "a few days" -- we have a hard
> (academic) deadline to meet!)

I took a look at the PDF and it looks great.  I'm looking forward
to getting some cycles to put a couple of packages into it.

Some comments in no particular order, and some may be relevant for
Godi:

1) I think it would be a good idea to take a look at the Fink
   package management system that is used for Mac OS X

   http://fink.sourceforge.net

   I think they've dealt with many of the issues that we'll deal
   with and we can learn from their mistakes.  They've been around
   since Mac OS X 10.0, so that's been a while.

   Fink compiles libraries, binaries, etc and has a similar
   format as Godiva's files.

   The packaging specification is at

   http://fink.sourceforge.net/doc/packaging/index.php

2) To make updating the Godiva file easier for a new package and to
   prevent mistakes, say somebody updates the Version field and
   forgets to update Sources: have a %v replacement in the URL that
   uses the Version field.

3) Having a License field would be good for people to easily
   see what license the package is licensed under.

4) The Fink people split packages into SSL and non-SSL packages
   for distribution of Fink to countries where encryption is more
   restricted.  Maybe keep a field for this.

5) Have a Conflicts field if two different packages conflict?
   Say if you have hooks to Berkeley DB3 and DB4 and because they
   both have a db.mli, only one can be installed.  This ties into...

6) What about splitting libraries into two separate packages,
   one for interface files and one for the libraries?  That way you
   can have installed different .so files for different libraries
   and binaries that linked against them and not have the .mli files
   around.  I may be thinking too much of a C environment here.

7) Having a single sources_unpacksto may not handle all cases.  Fink
   has a rich set of settings for this that would be good to look
   at

   http://fink.sourceforge.net/doc/packaging/reference.php?phpLang=en

I think my major point is that has more packages use Godiva to
build and install and issues come up, it would be great to
reference Fink.  Definitely take a look at it.

Best,
Blair

-- 
Blair Zajac <blair@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners