Re: Versioning OCaml in Debian [Was: Re: Buglet in ocaml-ldconf]
On Thu, May 16, 2002 at 03:20:48PM +0200, Stefano Zacchiroli wrote:
> On Thu, May 16, 2002 at 12:52:55PM +0200, Denis Barbier wrote:
> > This is exactly why installing modules under /usr/local/lib/ocaml/3.04/
> > makes sense: when you upgrade to 3.05, you can recompile only the
> > modules you want now, and let less used modules survive in
> > /usr/local/lib/ocaml/3.04/. If ocaml 3.05 also search files under
>
> So you are proposing to follow the python way.
No, the Perl way.
Even if only one version of Perl can exist in Debian at a given time,
modules are put in versioned subdirectories. This is of course due to
Perl upstream policy, but I will explain below why I think it is a good
idea here too.
> This is really a big decision for we debian ocaml guys.
>
> Personally I think that ideally is a good idea but that practically is
> useless. These are my reasons:
> - python way is a mess and requires user knowledge of what is going on
> regarding the debian python policy
> - Python language changes between 2.0, 2.1 and 2.2 are such that they
> suggests to keep different version of the interpreter while ocaml
> language changes are smaller than those between versions
> - versioning is not really usefull for the final user! I think that the
> only situation in which the user may need different version of
> compiled ocaml source is if we find an ocaml package or library that
> doesn't work with a new upstream ocaml version. Such a situation can
> be better handled fixing the problem than keeping an old version (and
> almost useless if it's a library!)
I just read the (very interesting) 'OCaml packaging problems' thread on
Caml ML, and believe that you all forgot one point: some users may want
to handle OCaml files without knowledge of OCaml and OCaml tools. This
has been true about TeX for years; admins are told to install it, but
are unable to customize it nicely. Fortunately teTeX filled the gap and
provided a nice documentation which helped a lot, but it is still not
perfect.
IMO Perl versioning system is helpful because if an admin wants to know
if Perl module Foo is installed, he runs
$ locate Foo
/usr/local/lib/perl/5.6.0/Foo.pm
He then knows that he installed Foo module with perl 5.6.0. If he later
installed perl 5.6.1, this means that a breakage could be caused by
those different versions.
> > > 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.
> >
> > I don't understand the last sentence, could you please explain to me how
> > it is handled?
>
> All compiled ocaml objects carry a magic identifier and can be linked
> only between objects with the same magic id and by a compiler of the
> right version.
> Current upstream OCaml policy provides that, at each release of ocaml,
> all libraries will be rebuilt using the new compiler.
>
> Regarding the last sentence, I think that Sven would mean that no
> compilation incompatibility will usually arise. (If you are asking:
> "OCaml new releases aren't backward compatibile?" the answer is "not
> always" :-( )
But again, admin might not be an OCaml user. He must be told precisely
what to do when upgrading OCaml core or installing a package.
This can be accomplished by (a) giving explanations in official
documentation (b) giving explanations in distributed tarballs
(c) and if possible adopting an already well-used scheme.
I am not a Java addict, and thus am unable to fully understand what
Jacques Garrigue wrote, but his post
http://caml.inria.fr/archives/200205/msg00198.html
is attractive, especially the last sentence:
In my opinion simple (one variable), standard (think Java), and clean.
But I do not know if it exactly fits our needs.
Denis
--
To UNSUBSCRIBE, email to debian-ocaml-maint-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: