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 77871BC6C for ; Fri, 1 Feb 2008 16:03:42 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAH3DokfAXQImh2dsb2JhbACBWI5XAQEBCAopnWAB X-IronPort-AV: E=Sophos;i="4.25,290,1199660400"; d="scan'208";a="22059345" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 01 Feb 2008 16:03:42 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m11F3dLL022932 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 1 Feb 2008 16:03:41 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAH3DokfU436znmdsb2JhbACBWI5XAQEBAQEGBAYHChidYAE X-IronPort-AV: E=Sophos;i="4.25,290,1199660400"; d="scan'208";a="22059342" Received: from moutng.kundenserver.de ([212.227.126.179]) by mail4-smtp-sop.national.inria.fr with ESMTP; 01 Feb 2008 16:03:38 +0100 Received: from gate.lan.gerd-stolpmann.de (dslb-088-068-215-110.pools.arcor-ip.net [88.68.215.110]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1JKxQY0txp-0002Hm; Fri, 01 Feb 2008 16:03:38 +0100 Received: from [192.168.0.32] (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id D03BAC12A; Fri, 1 Feb 2008 16:03:37 +0100 (CET) Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system From: Gerd Stolpmann To: Stefano Zacchiroli Cc: caml-list@inria.fr In-Reply-To: <20080131090228.GB1479@takhisis.invalid> 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> Content-Type: text/plain Date: Fri, 01 Feb 2008 16:03:42 +0100 Message-Id: <1201878222.14203.19.camel@flake.lan.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18Vh+3Psv2AJFs1AOBNAi+mxQBlp6x00ebhXO+ WpjOkXbM6zqYaOrra5wSsA8p7KWEgMy0vmN4FkPuyDlBsH9G+2 uX1drsWhW9N1WDkNyxHQGeJuCLHjdLZ X-Miltered: at discorde with ID 47A334CB.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 donnerstag:01 zacchiroli:01 0100,:01 gerd:01 stolpmann:01 runtime:01 dependencies:01 dependencies:01 deps:01 deps:01 syntax:01 syntax:01 subset:01 Am Donnerstag, den 31.01.2008, 10:02 +0100 schrieb Stefano Zacchiroli: > On Wed, Jan 30, 2008 at 04:12:15PM +0100, Gerd Stolpmann wrote: > > > Or where you talking about runtime/development time dependencies? > > > > See, this question already demonstrates that dependencies are a not so > > easy concept. It is at least difficult to reach a common understanding > > what would have to be listed as dep and what not. We have dependencies > > that come into play at different times, and there are also conditional > > dependencies (i.e. you need this software only if you want to build this > > special feature). Then there is the question of how detailed the > > dependency relation is (versions, or about allowing to have only parts > > of software units as dependency). > > > > A formalization of deps needs some complexity in order to be useful, but > > that makes a common understanding of them more difficult. I have some > > doubts that we find a balance here, so my advice to leave a formal > > description of deps out. > > That it is trickier than listing a handful of make targets if out of > discussion. That it is *so* tricky that should not be addressed I > disagree with. > > All the required information you mention above are already a part of the > build instruction of whatever program library you find out there. The > INSTALL (or whatever) file should list the set of libraries which are > required to build properly that library; if some of them are optional, > they should be flagged as such. My question is: given that this kind of > information are already available, why shouldn't we refrain to describe > it with a common syntax which can help in understanding mechanically > interrelationships? > > Note that I'm not requesting to actually mandate the *use* of this kind > of information in whatever build system, but only to use "morale > suasion" on library/program authors to write them down in a parseable > syntax. > > 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: - Are software maintainers willing to provide the information in a formalized way? That would mean they had to understand the details of the formalization, and also had to maintain these data (e.g. respond to users who find errors etc.). Depending on how much detail the formalization can express, this can be very easy or tricky. - 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. _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?" (where "?" signals an optional dependency). 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. 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. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------