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.6 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id D18C7BC6C for ; Wed, 30 Jan 2008 19:12:38 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJVMoEfAXQImh2dsb2JhbACQJwEBAQgKKZ9a X-IronPort-AV: E=Sophos;i="4.25,278,1199660400"; d="scan'208";a="6753551" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Jan 2008 19:12:38 +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 m0UICXJb029538 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 19:12:38 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHRNoEfY2tfi/2dsb2JhbACwMQ X-IronPort-AV: E=Sophos;i="4.25,278,1199660400"; d="scan'208";a="8547224" Received: from tail.lionet.info ([216.218.215.226]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 19:12:32 +0100 Received: from [10.72.109.162] (nat-dip4.corp.yahoo.com [207.126.230.225]) (authenticated bits=0) by tail.lionet.info (8.13.8/8.13.6) with ESMTP id m0UICTAf068038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Jan 2008 10:12:29 -0800 (PST) (envelope-from vss@73rus.com) Message-ID: <47A0BE09.7010908@73rus.com> Date: Wed, 30 Jan 2008 10:12:25 -0800 From: Vlad Skvortsov User-Agent: Thunderbird 1.5.0.14 (Macintosh/20071210) MIME-Version: 1.0 To: Sylvain Le Gall Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system References: <479F0664.2070706@exalead.com> <47A045C1.7030603@exalead.com> <47A05C59.2070900@exalead.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (tail.lionet.info [216.218.215.226]); Wed, 30 Jan 2008 10:12:29 -0800 (PST) X-Miltered: at discorde with ID 47A0BE11.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bug:01 recompile:01 ocaml:01 unpack:01 versioned:01 vlad:98 rus:98 vlad:98 rus:98 wrote:01 caml-list:01 minor:01 tar:01 diff:02 diff:02 Sylvain Le Gall wrote: >>>> 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 >>> >>> >> So you need to get a separate copy of P_{i1}, unpack it, and run a diff >> by hand... And what will happen during the process of developing the >> patch? You will be working on your patch without version control >> system. Which is very uncomfortable, especially as you will be working >> on unfamiliar code - you will make mistakes, erase or modify important >> stuff, won't be able to easily rollback, branch or review your changes. >> You will have to play around with tar, diff, patch and merge by hand, >> make mistakes and create a mess. Any VCS can handle all these tasks easily. >> >> Unless your correction is very minor, you will have to either (a) import >> the project into your own favorite VCS, losing history and create a >> short-lived repository or be forced to track all future changes by hand; >> or (b) checkout the sources using the VCS the authors use - but then >> we're back at case one: you will have to potentially have all the >> version control systems used by all the software components you may want >> to contribute to, and also learn how to use them all. >> > > You are mixing software development and packaging. If you really want to > have something clean, you should avoid having changes into the source of > the upstream author (at least changes that should last). > I agree with this. The lower the entry barrier for the system, the better. The simplier the system, the better. I wouldn't use a system that forces me to install a new sexy VCS on N of my machines and learn a new workflow just to use some packaged module. My strong preference is that any package should be available for download via HTTP/FTP. The metadata (central package registry) can be versioned or not, I don't care, as long as I can publish my package with a single command. I really like the way it's done in Python, here is a link to my previous email on this topic: http://www.nabble.com/Re:-Re:-On-module-distribution-p14852553.html -- Vlad Skvortsov, vss@73rus.com, http://vss.73rus.com