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=1.1 required=5.0 tests=AWL,SPF_NEUTRAL 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 69652BC6C for ; Wed, 30 Jan 2008 09:51:02 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALzJn0fAXQInh2dsb2JhbACQJwEBAQgKKZ9C X-IronPort-AV: E=Sophos;i="4.25,276,1199660400"; d="asc'?scan'208";a="21967457" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 09:51:08 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0U8p1H8017796 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 09:51:01 +0100 X-IronPort-AV: E=Sophos;i="4.25,276,1199660400"; d="asc'?scan'208";a="7417227" Received: from peray.inria.fr (HELO ausone.inria.fr) ([128.93.8.98]) by mail1-relais-roc.national.inria.fr with SMTP; 30 Jan 2008 09:51:01 +0100 Received: by ausone.inria.fr (sSMTP sendmail emulation); Wed, _d Jan 2008 09:49:57 +0100 From: "Nicolas Pouillard" Cc: Berke Durak , caml-list Subject: Re: [Caml-list] [OSR] Ports-like package management system To: "daniel.buenzli" References: <479F0664.2070706@exalead.com> <1201629992-sup-8035@ausone.local> In-Reply-To: Date: Wed, 30 Jan 2008 09:49:52 +0100 Message-Id: <1201682550-sup-1783@ausone.inria.fr> User-Agent: Sup/git Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=-1201682997-864229-27517-8775-8-="; micalg="pgp-sha1" MIME-Version: 1.0 X-Miltered: at concorde with ID 47A03A75.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 dependencies:01 tarball:01 overkill:01 overkill:01 patched:01 tarball:01 libfoo:01 libfoo:01 cvs:01 pulled:98 git:98 caml-list:01 hump:02 hierarchy:03 X-Attachments: cset="UTF-8" type="application/pgp-signature" name="signature.asc" name="signature.asc" --=-1201682997-864229-27517-8775-8-= Content-Type: text/plain; charset=UTF-8 Excerpts from daniel.buenzli's message of Tue Jan 29 20:13:40 +0100 2008: > > Le 29 janv. 08 à 19:17, Nicolas Pouillard a écrit : > > > I think this was what Berke has in mind to. However the > > repository still > > becomes very large even if there only a few files by package. > > Then I don't understand anymore. So the system is still centralized in > the sense that all port files are under the same vcs at some location. > That is exactly the kind of thing I'd like to avoid. > > If you don't have a centralized system, then managing your package's > port file is at your discretion. The port file itself should describe > the various versions it provides of the package, their dependencies > and where you can find them. You have a local branch of the whole port hierarchy, that's why we're talking about DVCS. > >> For me this is too fine grained -- and this is also the reason why > >> you > >> want to integrate a vcs to your system. I would like to be able to > >> specify a version that the developer of the package deemed stable > >> enough to distribute, not a random revision. I strongly think that > >> tarball releases are enough, if there are simple and efficient tools > >> to produce them. Going down to the revision is overkill. > > > > Perhaps not so overkill for developers, if you've just patched a > > project, you > > need to update the package quickly and perhaps not want > > to have a > > release/tarball for each of them. > > Frankly this is not the average case, please try to solve the average > case, not the baroque ones. If you need to follow a project at the > patch level deal directly with the developer's repository. Browse the > hump and try to think about which projects you'd follow at that level > to use in your own projects - dealing with moving targets is annoying. > > Besides having such a fine grain will bother both package users (up to > which patch should I pull ?) and package developers (transient issues > due to a user that pulled up to a given patch). That's not a baroque case, I mean if you are responsible of libFoo and progBar, you perhaps want to quickly package progBar using the last version of libFoo. [...] > > I think that the upstream source can be > > either a tarball URL or a VCS URL. For upstream sources one can > > supports some > > VCSs (CVS, SVN, darcs, git, hg) since one only need to checkout. > > A system can always be complexified. I'd rather have something simple > that works. I strongly think the vcs should be kept outside the > package management system. I also would like to keep things simple... -- Nicolas Pouillard aka Ertai --=-1201682997-864229-27517-8775-8-= Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFHoDo1j+FCNw9dwLkRAvXnAJ9U+m+0AMozy6dqjjJhmJffwZmBpgCfRibV i64nNyPUo+orrE1brq1axHg= =dPwi -----END PGP SIGNATURE----- --=-1201682997-864229-27517-8775-8-=--