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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]