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.9 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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 1A010BC6C for ; Tue, 29 Jan 2008 18:56:38 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIT3nkfAXQImh2dsb2JhbACQHgEBAQgKKZdOhyM X-IronPort-AV: E=Sophos;i="4.25,270,1199660400"; d="scan'208";a="7393810" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 29 Jan 2008 18:56:37 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0THub4q017834 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 29 Jan 2008 18:56:37 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEL3nkdC+VyrkWdsb2JhbACQHgEBAQEHBAYJGQWXT4cj X-IronPort-AV: E=Sophos;i="4.25,270,1199660400"; d="scan'208";a="8506370" Received: from ug-out-1314.google.com ([66.249.92.171]) by mail3-smtp-sop.national.inria.fr with ESMTP; 29 Jan 2008 18:56:36 +0100 Received: by ug-out-1314.google.com with SMTP id k40so211203ugc.18 for ; Tue, 29 Jan 2008 09:56:36 -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=WZbXB2vntNXMWh4G3+M7pNZebFlm1sdO1++ukquXnCA=; b=BpQfdB+yC8A2HYTRVwq/O5BbWJKmoJqxKqN+lrPitxaruaHvxMGJtvwflWlJ/68m10qs2G8roiYB99VfJdCeB2Iy5f2HNDtWcTsbLiHZjXlurwCDSAjcZSR5PaiUBuy6O7v37wNhEb+Y4YvYF6wOiBVw8IUunsEK7fjcYU+Y0do= 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=bwdSLH+pGRnYqDcJ67yKONlYM/k+qoMHt/Af1sTVnP1C8zip4hxwonE8DAIKqvLXTMbhqnXdhMPo4UDUVvBJLOkaGZCxZ2+5uTzHHYQBtqxNRePYNf4710Cq5vAtYCD4Lq9SMam4lYhQT4+9vca0wCpXwOmyKCE3dJg3hhyhmL4= Received: by 10.67.15.6 with SMTP id s6mr1681983ugi.82.1201629395823; Tue, 29 Jan 2008 09:56:35 -0800 (PST) Received: from ?192.168.3.139? ( [85.2.26.102]) by mx.google.com with ESMTPS id 27sm3415968ugp.19.2008.01.29.09.56.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Jan 2008 09:56:35 -0800 (PST) Cc: Caml-list List Message-Id: From: =?ISO-8859-1?Q?B=FCnzli_Daniel?= To: Berke Durak In-Reply-To: <479F0664.2070706@exalead.com> 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 18:56:37 +0100 References: <479F0664.2070706@exalead.com> X-Mailer: Apple Mail (2.915) Sender: =?ISO-8859-1?Q?Daniel=20B=FCnzli?= X-Miltered: at discorde with ID 479F68D5.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 berke:01 durak:01 cvs:01 versioned:01 tarball:01 tarballs:01 foo:01 dependencies:01 tarball:01 overkill:01 yaron:01 minsky:01 sunk:98 Le 29 janv. 08 =E0 11:56, Berke Durak a =E9crit : > We thus need versions, and lots of them! We need to base our > developer packages on a version control system, in the style of BSD > ports. BSD ports are usually based on CVS, sometimes on Subversion. My experience with bsd-like port systems (at least darwinports) is =20 that _port description files_ are versioned. But the bits they compile =20= are tarball releases, they do not pull directly out of the projects' =20 vcs to install your local copy. I would be all in favor of using somehting like darcs2 because it is =20 what I use. However I don't think it is a good idea to impose a vcs to =20= developers, they should be free to use their own. I don't understand =20 why you don't want to rely on tarballs, one per version, with a =20 facility to quickly create and upload them. > As we are looking to increase collaboration, having a single point of > contention is a serious limitations of these centralized systems; > we'll prefer more recent "distributed" version control system. You are right everyone should be able to publish its package on its =20 own server and mirrors (it also solves the problem of who is going to =20= pay for the infrastructure). But this has nothing to do with =20 distributed vcs. > Assume you are writing a program FOO and want to use a package BAR > available from bar.org. You tell ocamlbuild by adding some tag such > as > > : require(http://bar.org/repository/) This is good, FOO's dependencies are explicit. However I'm not sure a =20= direct uri is a good thing, you'll need something to be able to =20 specify alternate download sites. The package name + version =20 specification should be decoupled from the uri you use to access it. =20 Even if you do that nothing prevents you to implement this over plain =20= http. E.g. you have download locations uri1 uri2, and a package-name =20 and version-name then you try to download from uri1/package-name/=20 version-name and then if it fails uri2/... Of course in that case =20 you'll need digests. > Of course it should be possible to specify a particular revision... For me this is too fine grained -- and this is also the reason why you =20= want to integrate a vcs to your system. I would like to be able to =20 specify a version that the developer of the package deemed stable =20 enough to distribute, not a random revision. I strongly think that =20 tarball releases are enough, if there are simple and efficient tools =20 to produce them. Going down to the revision is overkill. > I know there is Omake, Having used ocamlbuild for caml projects, for me it is out of question =20= to return to something make-like. Le 29 janv. 08 =E0 14:11, Yaron Minsky a =E9crit : > It would also be nice to have a set of versions of the various =20 > libraries that hang together, as GODI does. Otherwise, problems in =20= > the case where there are packages A, B and C where A depends on B =20 > and C and B depends on C. You need a version of C that works with =20 > your versions of A and B, or you're sunk. So some central repo =20 > where you can maintain a set of "safe" versions would allow for a =20 > developer to ask for a easily pull a collection of working libraries. These are the kind problem you get when you go distributed. For =20 emergencies you need at least an override mechanism (use this version =20= instead of that one to build all packages). The rest should be solved =20= by cooperation between developers. But nothing prevents someone to =20 construct a cathedral, godi-like, collection of packages well tested =20 to work toghether and that you will use as your only source. It is =20 easy to build a centralized system on a distributed one, but the =20 converse is not true. At the risk of repeating myself I'll point again to my partial mod =20 proposal [1], some of the ideas there could be recast more thightly =20 with ocamlbuild as is propose above. This would certainly also =20 simplify the proposal (which was supposed to be a tool really =20 separated from ocamlbuild). Best, Daniel [1] http://erratique.ch/writings/mod.pdf=