From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA27453; Sat, 17 Apr 2004 08:29:31 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA27908 for ; Sat, 17 Apr 2004 08:29:30 +0200 (MET DST) Received: from calmail-cl.berkeley.edu (mailfarm.Berkeley.EDU [128.32.61.106]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3H6TSYM004845 for ; Sat, 17 Apr 2004 08:29:29 +0200 Received: from [64.162.212.212] (HELO tallman.kefka.frap.net) by calmail-cl.berkeley.edu (CommuniGate Pro SMTP 4.1.8) with SMTP id 17807151; Fri, 16 Apr 2004 23:29:27 -0700 Received: by tallman.kefka.frap.net (sSMTP sendmail emulation); Fri, 16 Apr 2004 23:28:31 -0700 Date: Fri, 16 Apr 2004 23:28:31 -0700 From: Kenneth Knowles To: Blair Zajac Cc: William Lovas , caml-list Subject: Re: [Caml-list] build tools - good vs. fast, both cheap Message-ID: <20040417062831.GB28488@tallman.kefka.frap.net> References: <1082126288.20063.69.camel@pelican.wigram> <20040416215308.GA21540@force.stwing.upenn.edu> <4080C4EC.1298A807@orcaware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4080C4EC.1298A807@orcaware.com> User-Agent: Mutt/1.5.6i X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; knowles:99 caml-list:01 advocating:01 model:01 2004:99 blair:01 zajac:01 lovas:01 owen:99 owen:99 fink:01 fink:01 sourceforge:01 compiles:01 binaries:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I don't want to be redundant, but certainly Gentoo's ebuilds (which I'm *not* advocating as an exact model) are very similar too. If you haven't checked 'em out then you should, but it seems like you've covered most everything that they have, and then some. Kenn On Fri, Apr 16, 2004 at 10:47:24PM -0700, Blair Zajac wrote: > 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 > 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 ------------------- 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