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.7 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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id DD6A6BC6C for ; Tue, 29 Jan 2008 20:13:41 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAL0Jn0fAXQInh2dsb2JhbACQJQEBAQgKKZdThyc X-IronPort-AV: E=Sophos;i="4.25,271,1199660400"; d="scan'208";a="8509886" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 29 Jan 2008 20:13:41 +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 m0TJDaqp030561 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 29 Jan 2008 20:13:40 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADwKn0dA6ba9i2dsb2JhbACQJQEBAQgEBAkKEQWXVoco X-IronPort-AV: E=Sophos;i="4.25,271,1199660400"; d="scan'208";a="7397677" Received: from nf-out-0910.google.com ([64.233.182.189]) by mail1-smtp-roc.national.inria.fr with ESMTP; 29 Jan 2008 20:13:40 +0100 Received: by nf-out-0910.google.com with SMTP id g13so270051nfb.7 for ; Tue, 29 Jan 2008 11:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=g6UJQkdzJMQpEwBAkDuWni2GPUGwNCtMgjPIhQ/z42M=; b=VFOYyirT3PWrWrkRavYmaQHHb0DNq5QNSeP+Vpfuq0DnhGyGufdB+4gVYmKVXy2RQO71GdNkaqEEYCN/F4OlC7+80PXl2I1MWSBHe5gpkpzw2qi7SffQeRCklfKS79pQHQjev6c60IdyEo0I9ZupZl6LcOHntFZ3rwfYo9rINHI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=nUJ4ZQD7Sl5EyNyCX2sv2n5GiKIfLBDVzy4IbjQhHCy/JDtyKCVfDPN5+1f65AhYm52oMwnFVab9Bb57rytXYbjf5uGv0LApTHsTTYshSzdtvSk/xGzjxY5mP8hRtWeVXGq463GQSBUO+F0kIC5OIhv66GogR5MKAi808ojzVV0= Received: by 10.78.184.2 with SMTP id h2mr10095973huf.27.1201634019648; Tue, 29 Jan 2008 11:13:39 -0800 (PST) Received: from ?192.168.1.58? ( [85.0.102.207]) by mx.google.com with ESMTPS id f4sm57826nfh.31.2008.01.29.11.13.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Jan 2008 11:13:39 -0800 (PST) Cc: Berke Durak , caml-list Message-Id: From: =?ISO-8859-1?Q?B=FCnzli_Daniel?= To: "Nicolas Pouillard" In-Reply-To: <1201629992-sup-8035@ausone.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Caml-list] [OSR] Ports-like package management system Date: Tue, 29 Jan 2008 20:13:40 +0100 References: <479F0664.2070706@exalead.com> <1201629992-sup-8035@ausone.local> X-Mailer: Apple Mail (2.915) Sender: =?ISO-8859-1?Q?Daniel=20B=FCnzli?= X-Miltered: at concorde with ID 479F7AE0.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 berke:01 dependencies:01 tarball:01 overkill:01 overkill:01 patched:01 tarball:01 dependencies:01 cvs:01 pulled:98 git:98 caml-list:01 hump:02 Le 29 janv. 08 =E0 19:17, Nicolas Pouillard a =E9crit : > I think this was what Berke has in mind to. However the =20 > 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 =20= the sense that all port files are under the same vcs at some location. =20= 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 =20 port file is at your discretion. The port file itself should describe =20= the various versions it provides of the package, their dependencies =20 and where you can find them. >> For me this is too fine grained -- and this is also the reason why =20= >> 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 =20 > project, you > need to update the package quickly and perhaps not want =20 > to have a > release/tarball for each of them. Frankly this is not the average case, please try to solve the average =20= case, not the baroque ones. If you need to follow a project at the =20 patch level deal directly with the developer's repository. Browse the =20= hump and try to think about which projects you'd follow at that level =20= 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 =20= which patch should I pull ?) and package developers (transient issues =20= due to a user that pulled up to a given patch). Another thing you may want to consider is that a "released" package =20 may need less (build) dependencies than a direct pull from a =20 repository (e.g. files generated using custom tools, etc.). > I think that the upstream source can be > either a tarball URL or a VCS URL. For upstream sources one can =20 > 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 =20= that works. I strongly think the vcs should be kept outside the =20 package management system. Best, Daniel