Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Project Proposals
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-05-16 (18:52)
From: Stefano Zacchiroli <zack@c...>
Subject: Re: [Caml-list] OCaml packaging problems
On Thu, May 16, 2002 at 02:24:49PM +0400, Vitaly Lugovsky wrote:
>  Sure. But distribution packagers, like me, can't wait for
> such a decision. :(

Indeed: with debian we choose a solution to the problem because no one
proposed a standard policy. Now seems that a policy is just to be
issued, well for us, we are only asking to take _one_, _definitely_

> it will be very nice to have a possibility to split ocaml libraries
> into runtime and development parts. Dynamic libraries belongs to the

Already done in debian packages, for each package that ships a library
that contain shared objects we have two packages: one named libfoo-ocaml
and one named libfoo-ocaml-devel where 'foo' is the name of the library.
The former contains the shared objects, the latter contains all the
other developmente stuff.

> runtime part, and, then,  should be handled in an OS native way.
> For Unices it's a libraries located in one big pile like /usr/lib/

Yes, but not /usr/lib itself, something like /usr/lib/ocaml (what a
coincidence! :-) is better, anyway we have a polluted /usr/lib/ocaml
directory so that is better to choose something different like
/usr/lib/ocaml/shlibs or similar. See FHS for more details.


Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy | ICQ# 33538863 |
"I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!" -- G.Romney
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: