Re: Counter proposal for the multiple ocaml installed
On Tue, Oct 22, 2002 at 12:06:30PM +0200, Jérôme Marant wrote:
> En réponse à Sven Luther <luther@dpt-info.u-strasbg.fr>:
>
> > > So if I read correctly in your mind, the transition would happen
> > > like this:
> > > - ocaml 3.06 is in debian
> > > - you upload ocaml3.07 (version within the name). This package
> > > provides ocaml-3.07 and ocaml-base-3.07
> > > - we recompile packages against ocaml-3.07 and ocaml-base-3.07
> > > - when completed, we bump ocaml to 3.07 and remove ocaml3.07
> > Err, we remove 3.06, but i suppose this just was a typo.
>
> No, there was no typo. ocaml 3.06 is meant to be pushed out
> of the archive once ocaml 3.07 replaces it.
> ocaml3.07 (note the package name with the version within)
> is the package that we upload when 3.06 is still in the archive.
Ok, ...
I was more of thinking along the lines of uploading ocaml-3.06 and ocaml
(version 3.07). But your idea also has merit.
> > > I made assumption with respect to what you said, am I correct?
> >
> > Well, yes, this is the main idea. But then, we can also keep 3.06, but
> > not rebuild the libs for it.
>
> It is not possible as I described: the idea is to perform the
> final step once the transition is complete.
Mmm, let me think about it.
BTW, stefano proposed to upload ocaml-3.06 and ocaml-3.07, and have
ocaml being a dummy package depending on the version we like.
> > There is nothing stopping use from having many versions of ocam
> > linstalled at the same time, the only problem is with the libraries.
>
> Yes, and such problem is not worth it. I don't want to add a
> version number in my packages any times a new ocaml comes out.
> A new stable version of Ocaml should become the standard one
> as quick as possible, otherwise some people will find good
> reasons to keep old versions (like Georges Mariano with ioxml).
But there is no risk in providing older versions of the ocaml package,
if we clearly state that it is not the supported one, please upgrade,
and we don't build libraries ourselves, but let this be the sole
provence of the user.
> > > But the postgres problem happens at the end of the transition
> > > so we cannot avoid the problem anyway.
> >
> > Well, the difference is that ocaml is _not_ dependant on postgresql in
> > any way. In fact, if i were to ask the ftp-master to remove stefano's
> > library depending on postgreSQL from the archive, the same day all the
> > ocaml stuff will enter testing (unless i am missing something).
>
> I think testing works like this. It is a side effect.
Yes testing works this way, yet, is it really important that stefano's
postgreSQL bindings (if that is what they are) stop the whole of ocaml
3.06 from entering testing.
> > So if we had the new translation scheme, ocaml 3.06 would have entered
> > testing, as well as most of the libs, and only the problematic
> > libraries
> > would be delayed.
>
> So programs using such libs must not be recompiled against
> the new ocaml until the transition of such libs succeeded.
Err, why ? they can be rebuilt, for fixing bugs and so, using the old
ocaml suite, no problem with that. It _must_ even be something that our
scheme allows, or we may not be able to support security bugfixes, and
this is not what we want (and may make the security team unhappy).
> > > > provide a CVS snapshot (which is a good thing, like a mail from
> > > > jacques
> > > > in the caml list this morning shows you) is just an added benefit.
> > The
> > > > second added benefit, is that user having installed stuff into the
> > > > ocaml
> > > > 3.06 libdir will not have their setup broken by a ocaml 3.07
> > upload.
> > >
> > > User must not do manual install in /usr/lib/ocaml;
> > /usr/local/lib/ocaml
> > > is there for that propose.
> >
> > Yes, the problem is that :
> >
> > 1) ocaml does not yet support OCAMLPATH, nor the ability to simply
> > use two different directories for the standard libraries.
> >
> > This can be solved by having every user use a -I directive, but then
> > the -I +dir shortcut is broken also.
> >
> > 2) Most current ocaml libs try to install into `ocamlc -where`, and
> > you have to override it manually, most user will not bother with it,
> > and there are libraries out there where the Makefile does not make
> > such a change easy.
> >
> > Result is that unless we have this nicely working, many if not most
> > users will install in /usr/lib/ocaml, and we have to cope with that.
>
> Users have to read the README.Debian where it is written that
> they must absolutely not install modules in /usr/lib/ocaml, if
> they do it, it is at their own risk.
Well, yes, but even in the ocaml_packaging_policy and the README.Debian,
i am not using strong obligation, and make way for the above problems.
This is something we will force in ocaml 3.07, i hope.
> > And btw, the README.Debian says explicitly that they should install
> > into
> > /usr/local/lib/ocaml/3.06, not into /usr/local/lib/ocaml.
>
> Yes.
>
> > We can only count on this, or even enforce this when :
> >
> > ocaml is patched to support multiple installdirs, with a working
> > OCAMLPATH or something such. We can then even have multiple such path,
> > i
> > would suggest :
> >
> > OCAMLPATH = ~/ocaml/3.06; /usr/local/lib/ocaml/3.06;
> > /usr/lib/ocaml/3.06
> >
> > In this order.
>
> What is ~/ocaml/3.06 ?
It is for home installed libraries, for user not having writing rights
to /usr/local.
> > And for installs, findlib should be able to handle this properly, but
> > i
> > would patch ocamlc so that it provides :
> >
> > ocamlc -where => /usr/local/lib/ocaml/3.06
> > ocamlc -distwhere => /usr/lib/ocaml/3.06
> >
> > And maybe even have ocamlc -where to be able to distinguish between
> > running as root (or having rights to /usr/local/lib/ocaml/3.06) and
> > running as user, or maybe adding an :
> >
> > ocamlc -persowhere => ~/ocaml/3.06
> >
> > switch.
> >
> > But this is something that needs to be discussed with upstream, i hope
> > it will be solved for 3.07.
>
> I have no clue about this.
Well, i could patch ocaml so that it provides a -distwhere, this would
be some work, and i don't really have time for this. I will lobby
upstream for at least the OCAMLPATH issues, which is something that
already got mentioned in the caml list various times.
Friendly,
Sven Luther
Reply to: