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_
decision.

> 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.

Cheers.

-- 
Stefano Zacchiroli - undergraduate student of CS @ Univ. Bologna, Italy
zack@cs.unibo.it | ICQ# 33538863 | http://www.cs.unibo.it/~zacchiro
"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 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