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 (08:43)
From: Sven Luther <luther@l...>
Subject: Re: [Caml-list] OCaml packaging problems
On Wed, May 15, 2002 at 09:39:43PM +0400, Vitaly Lugovsky wrote:
> On Wed, 15 May 2002, Sven Luther wrote:
> > > Concerning this ld.conf issue, I disagree both with Sven Luther's solution
> > > (a tool that adds/removes lines from this file) and with Vitaly
> > > Lugovsky's suggestion (multiple configuration files in a directory).
> > 
> > Would you care to argument a bit more about this, apart from the 'it is
> > not the unix way' argument you give below that is.
> > 
> > and BTW, ocaml-ldconf does not really add/remove lines from the
> > /usr/lib/ocaml/ld.conf file, it uses two separate files
> > (/etc/ocaml/ld.conf and /var/lib/ocaml/ld.conf) which are modified and
> > used to generate the /usr/lib/ocaml/ld.conf.
> > 
> > It is a nice concept (even if it is me saying it) that clearly separate
> > the system administrator stuff (/etc/ocaml/ld.conf) from the
> > dpkg/rpm/whatever handled stuff (/var/lib/ocaml/ld.conf), with the
> > former taking precedence over the later. In no way does it modify the
> > way ocaml handles this, and is thus a purely external tool doing its
> > jjob correctly.
>  This concept looks like ls-R file in the teTeX distribution. And all
> packagers knows that this file is quite a problem. So, as for me,

Would you elaborate more on said problems ?
It is a bit different though, altough i see why you say it is similar.

> I choosed the way suggested by Xavier Leroy - every .so file have
> simlink in %_libdir/ocaml/site-lib/, while the other library stuff
> located in the separate directory.

Ok, if we go that way, it is okay by me, just a decision should be
taken, after a reasoned discussion, and after that we should stick to

That said, i _don't like_ the symlink idea, symlink are a nice thing,
but mainly in this kind of cases are used when you don't have an
integrated distribution, and no packaging system, and many people also
claim that symlink can cause lot of problems. It is more a workaround
for case where you cannot do things properly.

Then if we go that way (all stub libraries in one or two dirs), what
will happen, as far as debian and maybe other integrated distribution
are concerned, is that we will put the stub libraries in the directory
(/usr/lib/ocaml/shlibs or something such), and the rest of the stuff in
the subdirectory. There will be no symlink, and this needs a redesign of
the build process of all those libraries, an adaptation to things like
findlib and ocamlmakefile, and is quite big work, so best to do it for
after there is a final decision on the subject.


Sven Luther
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: