Re: [Caml-list] Package installation assumptions made by odb

[Romain Bardou <bardou@lsv.ens-cachan.fr>]

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