From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q1DDks0e006311 for ; Mon, 13 Feb 2012 14:46:54 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4BAN0SOU/RVdY2kGdsb2JhbABDhRCqcQgiAQEBAQkJDQcUBCOBcgEBAQQSAg8ECwENARscAgMMBgULDQICBRYLAgIJAwIBAgEREQEFARwTCAIeo3sKiyZLgnCEWj+IcwIFC4EkihEIBiEDAgUFBQcEAgQDBAoBAgcFBgEDBAQBDYQbDwIGBYJIgRYElTKHFIcRPYQE X-IronPort-AV: E=Sophos;i="4.73,412,1325458800"; d="scan'208";a="131147566" Received: from mail-bk0-f54.google.com ([209.85.214.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Feb 2012 14:46:48 +0100 Received: by bkcjg1 with SMTP id jg1so6125323bkc.27 for ; Mon, 13 Feb 2012 05:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=0/Bp4HX97hsveOXIoIFh8fvqZgdCy3aSDAbsOfUgUFA=; b=PpTC/BgIj2sTF3LXpFQnhNMIBXTGQrpPaekDXpZWa+DuTfZmYfICFY/2TmFEzDpSgP YnT3AkJgO+vj0gzzCBkxVCh0UsNjpUOspNPUmtwe3UmLxydPzYlbaQXhkfiUXsvoQ+qy jHqcVn+DSEOd0ioPR4ZefB4Wnjyyiphz2H/A0= Received: by 10.204.148.79 with SMTP id o15mr7296002bkv.33.1329140808285; Mon, 13 Feb 2012 05:46:48 -0800 (PST) Received: from ?IPv6:2a02:2f02:1022:9000:a49d:b3d7:3b86:4505? ([2a02:2f02:1022:9000:a49d:b3d7:3b86:4505]) by mx.google.com with ESMTPS id i2sm46400237bkd.10.2012.02.13.05.46.46 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 05:46:46 -0800 (PST) Message-ID: <4F391445.3040600@gmail.com> Date: Mon, 13 Feb 2012 15:46:45 +0200 From: =?UTF-8?B?VMO2csO2ayBFZHdpbg==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <4F36D930.70008@gmail.com> <4F390A57.2020209@gmail.com> <4F39128D.7020706@lsv.ens-cachan.fr> In-Reply-To: <4F39128D.7020706@lsv.ens-cachan.fr> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] Package installation assumptions made by odb On 02/13/2012 03:39 PM, Romain Bardou wrote: > Le 13/02/2012 14:04, Edgar Friendly a écrit : >> On 02/13/2012 06:01 AM, Arnaud Spiwack wrote: >>> I see an immediate problem with packages that install several executable >>> files (for instance, Melt provides a library and a collection of tools, >>> none of them named melt, by the way). I haven't spent time looking more >>> than superficially into oasis or odb yet, but it strikes me as a >>> possibly important limitation. >>> >> >> It looks like the executable is now named melt-build. In this case, odb >> would expect the melt project name to be "melt-build" so that its simple >> logic can detect if melt is already installed. This does not have any >> affect beyond changing the name that must be typed on the command line >> to install melt (`odb melt-build` instead of `odb melt`), and the name >> for dependencies by other projects (projects depending on melt would >> have to specify `dep=melt-build` instead of `dep=melt`). >> >> Also, if melt installs an ocamlfind library named melt, then its odb >> package name could be melt or melt-build, depending on which part of >> melt should be used to detect its installation. At the moment, odb >> doesn't really do version handling (mainly because it's difficult to get >> a version number from an executable), although this is a weakness where >> odb might improve. >> >> This assumption of executables and libraries being named the same as the >> package isn't critical to the design of odb, it's just a simplifying >> assumption that works quite well (and would work for melt up to the last >> version when its executable was renamed). If there's good reason to have >> more complex installed-program detection, this is easily doable, but the >> workarounds are simple enough at the moment that this doesn't seem to be >> a problem. >> >> E. >> > > Hello, > > I agree with Arnaud: although this behavior is simple to implement and understand (which is good) I see several cases where it would be a problem. For instance, I'm currently working on a suite of > tools named like foo-feature1, foo-feature2, foo-feature3 and so on. The package would obviously be named foo, but it does not make sense to have a single "foo" executable. It does not make sense to > have once package per executable either. So I guess you need some way to override this behavior when needed. Can odb extract this kind of information from an _oasis file, or from a META file? I'm not > very familiar with those. > > Regarding Melt, I'm a bit confused: you say in this mail that "its odb > package name could be melt or melt-build, depending on which part of > melt should be used to detect its installation". But in your guidelines it is written: "Programs that are both should do both". By the way, Melt actually installs two libraries: Melt and Latex. > > Regarding the version number, if you need to define a standard I think it would be good if this standard was to call the executable with the "-version" option. It is, after all, the behavior of > "ocamlc". This does not work for libraries though; here there are several possibilities: > - compute a hash of the .cma / .cmxa, but you need a database of hashtables -> version; > - dynamically link with the .cma / .cmxa, assuming a module "Version" with a variable containing the version (but this is not very practical for many reasons). - Use the 'version' from the library's META file (if any): $ ocamlfind query -format '%v' sexplib 7.0.4 Best regards, --Edwin