Re: Buglet in ocaml-ldconf
On Wed, May 15, 2002 at 10:34:01PM +0200, Denis Barbier wrote:
> On Wed, May 15, 2002 at 06:41:34PM +0200, Remi VANICAT wrote:
> [...]
> > his suggestion :
> > "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)
> > - Packages for additional Caml libraries install their shared libraries
> > in /var/lib/ocaml/shlibs, either directly or via a symlink.
> > "
>
> Thanks for these explanations.
> I am an OCaml newbie, so I may be fully wrong, but it does not seem to
> solve all problems:
> * As pointed out by Matt, all tools should be consistent.
> The ocaml_packaging_policy document could be enhanced to deal with
> hand installed packages, so that all tools must conform to it.
> It would be simpler if OCaml itself had such a policy ;)
My opinion on this (based on some other mail exchange on this thread or
on the caml-list) would be to simply add /usr/local/lib/ocaml by default
to /etc/ocaml/ld.conf, and so everything hand installed should go there.
Ideally, we should get upstream to change the format of the ld.conf
file, so that we need only two such files, and have the tool work
directly on it.
> * Proposed scheme do not handle versioned dependencies.
> There are no problem with Debian packages, which themselves
> have versioned dependencies, But if you compile and install
> your own modules and then upgrade OCaml, there are trouble.
There is no versionning support in ocaml libraries anyway, it is an open
problem that has some theoretical implications, so it will not arrive
that soon (and i don't believe upstream is very keen on this kind of
things anyway).
> > by the way he had also said :
> > "(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.)
> > "
>
> Nice, if all libraries go into /var/lib/ocaml/shlibs/, ocaml-ldconf
> becomes useless. But again, it would be simpler if this policy
> was dictated by OCaml itself.
Yes, and especially if there would be a clear policy (from upstream)
about this.
> IIRC Perl paths in Debian have changed at every Debian release (I am
> of course not referring to change in directory names containing Perl
> version numbers ;)), which is very confusing. Hopefully their current
> policy seems rather good, and it should not need to change in a near
> future. I hope OCaml will avoid this annoyance ;)
> IMO an OCaml policy should focus on these issues:
> * Do we support simultaneous versions, as python does?
No, ocaml (upstream) is not up to it, and it would be a mess.
> * Installation path for core OCaml
> * Installation path for Debian OCaml packages
These two could be the same dirs, like it is done now.
> * Installation path for local modules
These we put into /usr/local/lib/ocaml.
> * How to upgrade OCaml when locally installed modules do exist?
This is a mess.
Current upstream policy and (strong) recomendation on this is to rebuild
everything once a new version of ocaml is released (your upgrade), so
this does not make sense anyway. If it is only a minor change, then it
is handled transparently anyway.
> This is not a criticism against the current ocaml_packaging_policy,
> which is a nice document, but focuses only on packaging.
Yes, sure, i did it in haste to help fellow package maintainer, it
should be expanded and foolproof-read (and spelling errors corrected)
before it is any true use. I don't think i am a very good writter for
this kind of stuff though.
That said, there is no need of deciding on this before woody gets
finally released.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to debian-ocaml-maint-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: