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.3 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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 61867BC6C for ; Wed, 30 Jan 2008 14:55:25 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMsQoEfAXQInh2dsb2JhbACQJwEBAQgKKZ82 X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="7430861" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Jan 2008 14:55:25 +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 m0UDtAd3030787 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 14:55:25 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMsQoEdQW+UCh2dsb2JhbACQJwEBAQgKKZ82 X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="7430850" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Jan 2008 14:55:10 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JKDP9-0001n7-M0 for caml-list@inria.fr; Wed, 30 Jan 2008 13:55:07 +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 13:55:07 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Jan 2008 13:55:07 +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 13:54:57 +0000 (UTC) Message-ID: References: <479F0664.2070706@exalead.com> <47A045C1.7030603@exalead.com> <47A05C59.2070900@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 47A081BE.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 bug:01 recompile:01 ocaml:01 unpack:01 rework:01 packager:01 git:98 git:98 wrote:01 wrote:01 On 30-01-2008, Berke Durak wrote: > Sylvain Le Gall a écrit : >> On 30-01-2008, Berke Durak 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). Lets take an example: * you commit source of project C, version V1 into your VCS * you do everything required packaging, including some change to project C to make it compile (changeset P1) * upstream author publish project C, version V2 (changeset P2) between V1 and V2 * the changeset between P1 and P2 cannot merge ... So what help do you get from your VCS here? You will have anyway to rework it. Forcing a VCS is just a way to loose people who won't have access to your VCS... I don't see a real advantage of doing it... If people want to put sources of anyone under their own VCS, they can do it. You can do even something very clever: put a metadata about upstream VCS into the packaging metadata. This way you will be able to checkout upstream author VCS directly and be able to send them patches with their own VCS... Better than to have to do a patch or to convert darcs/hg/git changeset to send it... Example: File METADATA.opkg: Upstream-Email: moi@chezmoi.com Upstream-VCS: svn+ssh://chezmoi.com/mygreat-project/tags/1.0.0 or Upstream-VCS: darcs://chezmoi.com/mygreat-project@version_1.0.0 or Upstream-VCS: git://chezmoi.com/mygreat-project@version_1.0.0 (Upstream-VCS will be Of course, the file METADATA.opkg can and all the other packaging info can be stored in any VCS (svn for GODI today). >>> - 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. > > We are not forcing anyone to work using the selected VCS. We are just > asking them to regularly publish their software to the VCS. If they > directly work using the selected VCS, publishing commits will be easier > for them - but they can still work on a day-to-day basis using their own > VCS. > Do they have to merge their changes with packager changes? In this case, i really do think that upstream author won't publish their changes a lot. Regards, Sylvain Le Gall