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 EB3C6BC6C for ; Wed, 30 Jan 2008 10:39:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEbUn0fAXQImh2dsb2JhbACQJwEBAQgKKYEUnjE X-IronPort-AV: E=Sophos;i="4.25,276,1199660400"; d="scan'208";a="21969507" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 10:39:15 +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 m0U9dEVW008681 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 10:39:15 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJHUn0fBL1AZh2dsb2JhbACQJwEBAQgKKYEUnjA X-IronPort-AV: E=Sophos;i="4.25,276,1199660400"; d="scan'208";a="8528788" Received: from gw.exalead.com (HELO exalead.com) ([193.47.80.25]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 10:39:14 +0100 Received: from [192.168.204.148] (madpc064.exalead.com [192.168.204.148]) (authenticated bits=0) by exalead.com (8.14.0/8.14.0) with ESMTP id m0U9dDBc012186; Wed, 30 Jan 2008 10:39:13 +0100 Message-ID: <47A045C1.7030603@exalead.com> Date: Wed, 30 Jan 2008 10:39:13 +0100 From: Berke Durak User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Caml-list List , Sylvain Le Gall Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system References: <479F0664.2070706@exalead.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 47A045C2.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; berke:01 durak:01 berke:01 durak:01 ocaml:01 ocaml:01 tarball:01 wget:01 bug:01 recompile:01 error-prone:01 arbitrarily:01 wars:98 collateral:98 compile:01 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. 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. 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... 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. 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. 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. 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 - A build system integrated with the 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, -- Berke DURAK