caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Edgar Friendly <thelema314@gmail.com>
To: Arnaud Spiwack <aspiwack@lix.polytechnique.fr>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Package installation assumptions made by odb
Date: Mon, 13 Feb 2012 08:04:23 -0500	[thread overview]
Message-ID: <4F390A57.2020209@gmail.com> (raw)
In-Reply-To: <CAMoPVjfAhRwzY_MUpLOqUGwbg02J5XKJR4=KtW8vTRnqgq+HEA@mail.gmail.com>

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.

  reply	other threads:[~2012-02-13 13:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-11 21:10 Edgar Friendly
2012-02-13 11:01 ` Arnaud Spiwack
2012-02-13 13:04   ` Edgar Friendly [this message]
2012-02-13 13:39     ` Romain Bardou
2012-02-13 13:46       ` Török Edwin
2012-02-13 13:53       ` Edgar Friendly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F390A57.2020209@gmail.com \
    --to=thelema314@gmail.com \
    --cc=aspiwack@lix.polytechnique.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).