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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 3DFA8BC6C for ; Thu, 31 Jan 2008 10:02:34 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADEdoUfAXQImh2dsb2JhbACQKgEBAQgKKZtf X-IronPort-AV: E=Sophos;i="4.25,283,1199660400"; d="scan'208";a="7461231" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 31 Jan 2008 10:02:34 +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 m0V92Xb0021980 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 31 Jan 2008 10:02:33 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKYdoUdDz4He/2dsb2JhbACsRg X-IronPort-AV: E=Sophos;i="4.25,283,1199660400"; d="scan'208";a="22006755" Received: from fettunta.fettunta.org ([67.207.129.222]) by mail4-smtp-sop.national.inria.fr with ESMTP; 31 Jan 2008 10:02:32 +0100 Received: from aquarium.takhisis.invalid (unknown [10.17.0.10]) by fettunta.fettunta.org (Postfix) with ESMTP id 813F3181DE for ; Thu, 31 Jan 2008 09:02:30 +0000 (UTC) Received: by aquarium.takhisis.invalid (Postfix, from userid 1000) id B4F41124302; Thu, 31 Jan 2008 10:02:28 +0100 (CET) Date: Thu, 31 Jan 2008 10:02:28 +0100 From: Stefano Zacchiroli To: caml-list@inria.fr Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system Message-ID: <20080131090228.GB1479@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201705935.9179.102.camel@flake.lan.gerd-stolpmann.de> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Miltered: at discorde with ID 47A18EA9.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 runtime:01 dependencies:01 dependencies:01 deps:01 deps:01 syntax:01 syntax:01 subset:01 cheers:01 zacchiroli:01 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. 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