From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id C4FDDBC6C for ; Wed, 30 Jan 2008 17:33:19 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKE1oEfAXQImh2dsb2JhbACQJwEBAQgKKYEUnig X-IronPort-AV: E=Sophos;i="4.25,278,1199660400"; d="scan'208";a="21985562" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 17:33:19 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0UGXF85025851 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 17:33:19 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABg1oEfY87Fk/2dsb2JhbACReZ4n X-IronPort-AV: E=Sophos;i="4.25,278,1199660400"; d="scan'208";a="7437693" Received: from unknown (HELO elehack.net) ([216.243.177.100]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Jan 2008 17:33:17 +0100 Received: by ahijah.elehack.net (Postfix, from userid 1001) id 0BF392E049; Wed, 30 Jan 2008 10:34:02 -0600 (CST) To: caml-list@inria.fr Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system References: <479F0664.2070706@exalead.com> <47A045C1.7030603@exalead.com> From: Michael Ekstrand Date: Wed, 30 Jan 2008 10:32:20 -0600 In-Reply-To: (Sylvain Le Gall's message of "Wed\, 30 Jan 2008 09\:53\:34 +0000 \(UTC\)") Message-ID: <871w7zgtpn.fsf@jehiel.elehack.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at discorde with ID 47A0A6CC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 le-gall:01 wget:01 ocaml:01 cvs:01 tarballs:01 tarballs:01 orthogonal:01 cvs:01 compiler:01 gentoo:01 gpg:01 merit:98 nightly:98 caml-list:01 Sylvain Le Gall writes: > Using a simple wget/rsync (you can redevelop it in OCaml) is far > more simple than to use a VCS. Hear, hear. I think that it's somewhat strange to incorporate the source for all packages into one massive VCS, and it looks like that's what's been proposed. Forgive me if I'm rehashing things that have already been brought up, but I think that some kind of hybrid thing is good, and that Sylvain has some excellent points. For the general case of package management, you need 2 things, metadata and source, and those two should probably not be managed together. The Ports-like systems all seem to do this well - you have a tree of metadata (usually managed via some VCS [FreeBSD uses Perforce and CVS], but easily distributed via rsync to end users). Metadata references tarballs. I don't see a whole lot of merit for hooking into upstream VCS for the general case, as most users will probably want to use released tarballs of everything except the few modules they're working on. Now, it makes a lot of sense to me to use a DVCS for managing the metadata, but that's entirely orthogonal to the systems used for managing sources. The DVCS metadata has the benefit of allowing developers to pull down a tree, version-control their changes as they incorporate controls to build newer/CVS versions, and the resubmit those to the master tree for distribution to users. Administrators can pull down a tree, version-control local adaptations (changing compiler options or whatnot), and re-sync with upstream in a controlled fashion. Also, for this, providing the ability to pull source from VCS would be a decent idea, so the developer can build on their local system, but this is primarily for development purposes and not for production or end-user distribution (in the general case). This could possibly be implemented by hooks to generate tarballs from the VCS -- yes, it has some build overhead, but it keeps the developers honest by making the path of least resistance require that their source stay in a quasi-releasable state. Whether this metadata looks like Debian build files, or like *BSD/Gentoo ports, or a tree of RPM SPEC files, doesn't much matter in my mind. To recap, my vision for this thing: - Tree of build control and dependency declaration files, managed with a DVCS, with end-user distribution (perhaps updated nightly from the VCS) via rsync. - Tarballs of upstream releases, published by upstream developers, and cached by the distribution project (i.e. a "distfiles" directory containing the sources for all software currently referenced by the tree, perhaps with old versions also). Now, to test code against the tree, the developer checks out a local copy of the metadata tree. They then go to the control files for their project, and modify them to say "get the source from over here" (adjusting version numbers, controls, etc. as appropriate). Then, they build, and everything should work smoothly, with minimal hassle. Of course, the CPAN-style proposal also sounds like a good idea. I'm just not so sure on this whole all-sources-in-one-tree thing - it seems like a significant amount of wasted space and strangeness. (Of course, if I'm misunderstanding what's being proposed, feel free to correct me!) - Michael -- mouse, n: A device for pointing at the xterm in which you want to type. Confused by the strange files? I cryptographically sign my messages. For more information see .