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 4DECBBC6C for ; Sun, 3 Feb 2008 21:21:50 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAHSxpUfAXQInh2dsb2JhbACQJQEBAQgKKYEUmRg X-IronPort-AV: E=Sophos;i="4.25,298,1199660400"; d="scan'208";a="22120160" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 03 Feb 2008 21:21:50 +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 m13KLmbc010203 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sun, 3 Feb 2008 21:21:49 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJCwpUdDz4He/2dsb2JhbACRd5kW X-IronPort-AV: E=Sophos;i="4.25,298,1199660400"; d="scan'208";a="8679216" Received: from fettunta.fettunta.org ([67.207.129.222]) by mail3-smtp-sop.national.inria.fr with ESMTP; 03 Feb 2008 21:21:48 +0100 Received: from aquarium.takhisis.invalid (unknown [10.17.0.10]) by fettunta.fettunta.org (Postfix) with ESMTP id 1ED941849F for ; Sun, 3 Feb 2008 20:21:47 +0000 (UTC) Received: by aquarium.takhisis.invalid (Postfix, from userid 1000) id 8D510D4023; Sun, 3 Feb 2008 21:21:45 +0100 (CET) Date: Sun, 3 Feb 2008 21:21:45 +0100 From: Stefano Zacchiroli To: caml-list@inria.fr Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system Message-ID: <20080203202145.GA15741@takhisis.invalid> Mail-Followup-To: caml-list@inria.fr References: <479F0664.2070706@exalead.com> <20080130123705.GA21900@pulp.rsise.anu.edu.au> <1201702034.9179.59.camel@flake.lan.gerd-stolpmann.de> <20080130133741.GB20725@takhisis.invalid> <1201705935.9179.102.camel@flake.lan.gerd-stolpmann.de> <20080131090228.GB1479@takhisis.invalid> <1201878222.14203.19.camel@flake.lan.gerd-stolpmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201878222.14203.19.camel@flake.lan.gerd-stolpmann.de> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Miltered: at concorde with ID 47A6225C.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; zacchiroli:01 zack:01 0100,:01 gerd:01 stolpmann:01 subset:01 deps:01 formalized:01 deps:01 formalize:01 ocaml:01 findlib:01 usr:01 ocaml:01 ocamlfind:01 On Fri, Feb 01, 2008 at 04:03:42PM +0100, Gerd Stolpmann wrote: > > Regarding the kind of relationships which can be described and how > > (alternatives, version requirements), the major GNU/Linux distribution > > families have a quite large subset of supported feature which are not so > > tricky and are agreed upon. > Interesting view, but it still doesn't convince me that including a > formalization of deps would be worth the effort. I would like to hear > more opinions about this: Fair enough. Socially however, I doubt you will be able to seek several opinions in this sub-sub-sub thread :), you should probably start a new thread or something such. I will answer for myself. > - Are software maintainers willing to provide the information in a > formalized way? That would mean they had to understand the details Wearing my hat of (not so widespread) software maintainer, it wouldn't make any difference. If I care about proper installation instruction I already have to maintainer a proper INSTALL file, maintaining a more formal dependency expression in a file won't be much of a difference. Actually, if the format spreads and the community reach an agreement on it, it would be even better since I can avoid writing useless prose to describe the deps in INSTALL, and just care of the dependency expression. (Note that in my case, since I'm also the Debian maintainer of my software, I'm also already maintaining the dependency expression, but I presume this is not a common case.) > - Is this so useful for the users that they really need it? I mean > the primary users would be the existing distribution systems > like GODI or Debian that already have formalizations for deps. > I expect that most end users won't directly install software, > and if so, it is likely that they run manually through the > the build package by package, so a description of deps in English > would be almost as useful as a formalization. In general, the usefulness for the users depends on the available tools using the dependency formalization. This is a like a chicken and egg problem: until we have the formalization we won't be able to show usefulness. I'm trying to catch the bus which is passing: if we are going to formalize software installation related stuff, I'll try to get it right without loosing information. Anyhow, regarding your end users point, I don't know for GODI since I'm not using it, but in Debian we have always kept in mind that users should be able to install OCaml libraries which are not packaged in Debian. So, for example, our default findlib configuration supports /usr/local/... The reason is that no packaging framework supports every piece of OCaml software out there. In this sense, end users do install software, and a dependency formalization would give us possibilities such as: - have a single system (ocamlfind based) to check if the required deps to compile a library or program are available In a word, it would get us nearer to CPAN's "perl Makefile.PL" 1-click installation procedure. > _If_ we agree that a formalization is useful, I am still of the > opinion the simpler the better. So maybe only a list of build > requirements, where some are flagged as optional. That would be a > simple string > > "pgk1 pkg2 pkg3? pkg4?" Full ACK: the simpler, the better. Something like that is fine with me, though I would like to see at least >= version checking. See below ... > Including version requirements has the disadvantage that it enforces a > certain syntax of the package names, and that there are several > solutions for comparing version strings. I'm less convinced about that (though we are getting into details here, whereas your bold "If" above is still to be settled). It is true that there are various syntaxes for versions, but they do entail different comparison results only in very corner cases. Take pkg-config, AFAIK it supports >= version comparisons supporting just one syntax for versions. It does work fine with 99.9999% of the software libraries out there. > For even more structure like alternatives, or mutual incompatibilities I > don't see how this could be processed in a uniform way. The package > systems are very different in this point. Agreed, also it is seldomly needed. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ............... now what? zack@{upsilon.cc,cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ? /\ All one has to do is hit the (15:57:15) Bac: no, la demo scema \/ right keys at the right time