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 q1DDdIgW005917 for ; Mon, 13 Feb 2012 14:39:18 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsBANcROU9XYriNmWdsb2JhbABEhRSoPoJdAQEBAQEICwsHFCeBcgEBBSMECwEFQBELGAICBRYLAgIJAwIBAgFFEwgCh3uqC4lmgS+KEQgGIQMCBQUEAQcGBAMECwIHBQYBAwgBhAUDIA8CBgWCSIEWBJsujGk X-IronPort-AV: E=Sophos;i="4.73,412,1325458800"; d="scan'208";a="131146336" Received: from 9.mo3.mail-out.ovh.net (HELO mo3.mail-out.ovh.net) ([87.98.184.141]) by mail4-smtp-sop.national.inria.fr with ESMTP; 13 Feb 2012 14:39:12 +0100 Received: from mail622.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with SMTP id 24C0EFFB95A for ; Mon, 13 Feb 2012 14:39:29 +0100 (CET) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 13 Feb 2012 15:39:07 +0200 Received: from unknown (HELO ?138.231.81.152?) (romain%bardou.fr@138.231.81.152) by ns0.ovh.net with SMTP; 13 Feb 2012 15:39:03 +0200 Message-ID: <4F39128D.7020706@lsv.ens-cachan.fr> Date: Mon, 13 Feb 2012 14:39:25 +0100 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: caml-list@inria.fr X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net) References: <4F36D930.70008@gmail.com> <4F390A57.2020209@gmail.com> In-Reply-To: <4F390A57.2020209@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 1330532216455878432 X-Ovh-Remote: 138.231.81.152 () X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeegtddrtdefucetggdotefuucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucenucfhrhhomheptfhomhgrihhnuceurghrughouhcuoegsrghrughouheslhhsvhdrvghnshdqtggrtghhrghnrdhfrheqnecujfgurhepkfffhfgfggfvufhfjggtgfesthekrgdttdefje X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeguddrudduucetggdotefuucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucenucfhrhhomheptfhomhgrihhnuceurghrughouhcuoegsrghrughouheslhhsvhdrvghnshdqtggrtghhrghnrdhfrheqnecujfgurhepkfffhfgfggfvufhfjggtgfesthekrgdttdefje X-Validation-by: bardou@lsv.ens-cachan.fr Subject: Re: [Caml-list] Package installation assumptions made by odb 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). My 2 cents, -- Romain Bardou