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_SOFTFAIL autolearn=disabled version=3.1.3 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 8352FBC6C for ; Wed, 30 Jan 2008 10:53:46 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAIPYn0fAXQInh2dsb2JhbACQJwEBAQgKKYEUnjY X-IronPort-AV: E=Sophos;i="4.25,276,1199660400"; d="scan'208";a="7420308" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Jan 2008 10:53:46 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0U9rZNT020574 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 10:53:46 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEPYn0dQW+UCh2dsb2JhbACQJwEBAQgKKYEUnjU X-IronPort-AV: E=Sophos;i="4.25,276,1199660400"; d="scan'208";a="8529301" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 10:53:43 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JK9dV-0007l4-8J for caml-list@inria.fr; Wed, 30 Jan 2008 09:53:41 +0000 Received: from ks300734.kimsufi.com ([91.121.65.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 09:53:41 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 09:53:41 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: [OSR] Ports-like package management system Date: Wed, 30 Jan 2008 09:53:34 +0000 (UTC) Message-ID: References: <479F0664.2070706@exalead.com> <47A045C1.7030603@exalead.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com User-Agent: slrn/0.9.8.1pl2 (Debian) Sender: news X-Miltered: at concorde with ID 47A0491F.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; le-gall:01 berke:01 durak:01 berke:01 durak:01 ocaml:01 ocaml:01 wget:01 wget:01 tarball:01 bug:01 recompile:01 error-prone:01 arbitrarily:01 wars:98 On 30-01-2008, Berke Durak wrote: > Sylvain Le Gall a écrit : >> Please don't go into this. If you want to talk about PM, don't talk >> about VCS. My point is that if you want to build something that last you >> should keep focus on PM, which is not really bound to VCS (like content >> of files is not bound to filesystem). There is no best VCS for doing PM. >> We just should handle a way to : >> * let anyone use a different VCS >> * be able to download at least a version of each different packages > > > The most simple way to handle this, to my mind: > > * distribute METADATA for packaging into ftp/http > > * put a link to the VCS inside METADATA, to tell where you can find most > > recent one > > We want to guarantee to the user that if she has installed Ocaml and the > Ocaml package system, she will be able to use any component packaged in > the system without having to install extra software. > > The Ocaml pakcage system must therefore include as a prerequisite all > the tools required for fetching data. Hence if we want to use a VCS as > part of the system, we must agree on one. > > The VCS selected, if any, doesn't have to be the one the developers use, > of course. (But there exist many VCS-to-VCS bridges, so it's not really > a problem.) > > Speed and portability are however important. > Using a simple wget/rsync (you can redevelop it in OCaml) is far more simple than to use a VCS. VCS-to-VCS is a dream. If have tried to use many, most of the times they are complicated to setup and don't work well. And of course wget/rsync are the fastest way to get data. > Now why would we want to use a VCS? > > * As a data storage and distribution mechanism > * For efficient updates > * For the ability to check out any revision > > These functions could be emulated by having a directory with a lot of > tarball snapshots and using wget. This may work for passive use of the > software but even for this limited use case, use of a VCS is much more > useful - efficient updates, storage of all intermediate revisions, > branches, and the possibility for the upstream author to directly work > on that VCS. Use rsync! > > But the aim of the Ocaml packaging system should be to foster > cooperation among Ocaml developers. That is why having a recommended > VCS and a standardized build system (or at least set of build commands) > is important. > > Assume we agree on a distributed VCS system S. Most Ocaml software will > be developed in its own S repository, hosted by the author. So we will > have programs P1, P2... with respective repositories S1, S2... > Assume that Mister Z don't want to use VCS S. Mister Z create a lot of great OCaml libraries... What do you do? > When you develop a program P you will have use programs P_{i1}, P_{i2}, > ... and thus have checkouts of repositories S_{i1}, S_{i2}, and so on. > If you find a bug in P_{i1} you can directly edit the checked out > version, recompile everything automatically by launching ocaml in P's > directory and thus debug P_{i1}. You can then locally commit your > changes to P_{i1} and then easily push the patch or send the diff to the > upstream author. > Send a patch to author of P_{i1}. This is the easiest way. diff -Nurd P_{i1} P_{i1}.new > If we don't use a VCS, this becomes much more difficult and error-prone. > > The increase in collaboration and productivity could be tremendous. > This requires close integration of the build and repository system and > agreement on a common VCS. > This also lead to be stuck with one VCS for the rest of our lives. It also prevents people who don't like/don't have time to learn VCS S, to contribute. > Now being able to use the software of your choice, plurality and > multiplicity of solutions are all good, but in this particular case this > hinders collaboration. > > It's as if everyone was using a different language! > > My intent was not to provoke VCS flame wars. But I think agreeing on a > VCS is important and a flame war or two is acceptable collateral damage > in the process of selecting one. > Looking at all the mail of this thread, i mainly read people talking about VCS R being faster than VCS S... > Now of course I don't have a precise idea of what the Ocaml packaging > system would be like, but I think the way to go is to : > > - Use a common distributed VCS system for storage and distribution of > source code, with multiple repositories > Lets choose a very simple storage system. Not a VCS. This too heavy and create too many complicated case. > - A build system integrated with the package management system, > Yes, if you do not force every software developers to use it and still provide a way to integrate their software into your package management system. > - A package management system able to manage arbitrarily many > versions or copies of the same software component, and compile any > program using an arbitrary selection of the required versions, Regards, Sylvain Le Gall