Re: [Caml-list] OCaml packaging problems

[Xavier Leroy <xavier.leroy@inria.fr>]

> I am going to prepare a new ocaml debian package which will support what
> you suggest, but still be compatible with the current way of doing
> things (using the external ocaml-ldconf program).
> [description omitted]

Looks good.  

> But there are two points i much would like a consensus being attained on :
> 
> 1)  What will be the exact name of these directories ? It would be a good
> idea, i think at least, if we choose the same name for all
> installations of ocaml, and not everyone choosing it's own directory.
> (or else we could have a ocaml option similar to -where which would
> give a pointer to these directories ? and have the choice of the
> directory highly configurable, maybe a -where_stub or something such ?)
> 
> Actually i have the proposition of "shlibs" from you, and "libexec" from
> Gerd and the findlib people. and then i feel myself "stublibs" should be
> a nice name too, especially since it is just the sub libraries we are
> speaking about, and not the .cma and other such ocaml libraries.

My proposal for "shlibs" was just for the sake of example, and isn't
very descriptive.  I like "stublibs" or "libexec" better, actually.

> 2) I think it would be nice to distinguish two such directories,
> /usr/lib/ocaml/shlibs for distribution native libraries (the packaged
> ones that follow the rule), and /usr/local/lib/ocaml/shlibs for hand
> installed packages.

Keep in mind that there is only one OCaml standard library directory.
So, non-packaged libraries tend to install in `ocamlc -where`/LIBNAME,
and would put their DLLs in `ocamlc -where`/stublibs.  Hence,
I'm not sure the second directory /usr/local/lib/ocaml/stublibs
would be used a lot.  But it doesn't hurt.

On a related issue, to facilitate the transition from the current
scheme, it might be worth adding /usr/lib/ocaml as a third
directory, at least for the next two releases or so.

> And should these two dirs be hardcoded into the ocaml suite, (as are
> /usr/lib and /lib into the C ld.so) ?

I don't think so.  The hardcoding in ld.so seems to come from a desire
to facilitate disaster recovery: even if the ld.so cache or
configuration files get accidentally wiped, a reasonable number of
dynamically-linked utility programs still run.  There is less to worry
about wiping OCaml's ld.conf file.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners