Re: [Caml-list] OCaml packaging problems

[Sven Luther <luther@lambda.u-strasbg.fr>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 6194 bytes --]

On Tue, May 14, 2002 at 10:54:52AM +0200, Xavier Leroy 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.

> The ld.conf mechanism was modeled after the /etc/ld.so.conf file used
> by the Unix dynamic loader.  It is intended to list a small number of
> standard directories that contain shared libraries, typically one
> directory for the "system" libraries (i.e. those provided by the OCaml
> core distribution), one for local extensions (e.g. /usr/local/lib),
> and perhaps one or two for especially large packages with many libraries
> (e.g. /usr/X11R6/lib).  

So, what is the way we want to handle this ? Do we put all stuff related
to libraries in a sub directory, like we were doing up to now, or do we
revert to the name space poluting 'all in the same dir' concept ? If you
do it the later way, this is a 180 degree turn from your previous
position, and the one followed by most current libraries.

Also, notice that in the above, you don't take into account the
libraries provided by the OS distributor, which upto now did put their
library stuff under a subdir of OCAMLLIBDIR.

> When you install a package that provides a C shared library, you don't
> install it in a package-dependent directory and add a line to
> /etc/ld.so.conf with this directory; you install in /usr/lib or
> /usr/local/lib, perhaps via a symbolic link.  I urge everyone to use
> the same scheme for OCaml shared libraries.

Well, if i remember well, the true C shared library is not really stored
in /etc/ld.conf, but rather in some other space, and it is only the
ldconfig tool which (from the manbpage)

       ldconfig creates the necessary links and cache (for use by
       the  run-time  linker,  ld.so)  to  the most recent shared
       libraries found in the directories specified on  the  com­
       mand line, in the file /etc/ld.so.conf, and in the trusted
       directories (/usr/lib  and  /lib).   ldconfig  checks  the
       header  and file names of the libraries it encounters when
       determining  which  versions  should  have   their   links
       updated.   ldconfig  ignores  symbolic links when scanning
       for libraries.

So if you trully want to do comparaisons, such a tool would be nice (and
one that handles different versions even better :)))

And about the symlink issue ? Why resort to it, if you can do it in a
more clean way ? And if you are afraid of lot of incompatible changes,
remember the ocaml-ldconf tool from the debian distribution handles our
problem well and without interference on how ocaml does handle it.

> (And, yes, I haven't followed this recommendation in some of the
> standard OCaml libraries (labltk) or some of my own extensions,
> but I've realized my error and intend to fix this in release 3.05.)

There is nbo clear policy on that, and everyone does it their own way,
or maybe the way they feel is the correct one, gathering it from how the
inria people do with the libraries they release. It is mostly a
guesswork thing, and would very much benefit from a 'standardisation' of
such practives.

Also, before you 'fix' things things in 3.05, maybe more based of a spur
of the moment decision you are taking (which may not be the case, but
seems so from your revirement from previous practices), i would very
much like to have a true and open discution on this important subject,
before any such decision is taken, but then, in the end it is you who
decide on this (and i can always do the patching for the debian package
:)))

> So, to summarize, I strongly suggest the following approach for RPMs
> or Debian packages:
> - The main Caml package can add one or two lines to ld.conf,
>   e.g. /var/lib/ocaml/shlibs (for libraries installed by other packages)
>   and /usr/local/lib/ocaml/shlibs (for local stuff)

Ok, but why not put them in subdir like it is done all over the place
right now ? (and what precedence will you use for the local over
standard packages ? Or coiuld you choose a finer granularity for such
choice ?)

> - Packages for additional Caml libraries install their shared libraries
>   in /var/lib/ocaml/shlibs, either directly or via a symlink.

Ok, i could live with that, _if_ you convince me that it is a better
solution than the one available right now. 

Also a quick note about name space pollution, mayube it is not an issue,
since you cannot anyway have two shared stub library of the same name,
even in two different directories, isn't it ? So there is nothing gained
by putting things in different dirs.

> This is simple, consistent with C shared libraries, and supports
> deinstallation of additional Caml libraries without any hassle.

Just two things to conclude, first notice that on most system, C
libraries are also put in subdirectories of /usr/lib, and this works ok,
which is not currently the case in ocaml, and second I would _much_ have
preferred you take such a stance 6 month ago, before we took the pain to
discuss a viable solution for the debian ocaml related packages, and i
lost times working on this back then.

Friendly,

Sven Luther
> 
> - 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