[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Counter proposal for the multiple ocaml installed



En réponse à Sven Luther <luther@dpt-info.u-strasbg.fr>:

> >   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.

This works like this for Python (and GCC) because people have to provide
multiple versions of libraries, one for each version.
We clearly don't want to do that but rather ease transitions, and
remove the old version of ocaml when possible.
We must tell the use we do not support old versions of ocaml.
 
> > > 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.

  Stating does not suffice, IMO. I'd prefer when upgrading forces
  the removal of packages (which happens on transitions), than
  breaking the system.

> > > > 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).

Package: A
Depends: B

Package: B
Depends: ocaml-base-3.06

Now, assume that you recompile B against ocaml-base-3.07.

Package: B
Depends: ocaml-base-3.07

And upgrading is still possible. But A will be broken.
How do you plan do handle such cases? 

...
> > What is ~/ocaml/3.06 ?
> 
> It is for home installed libraries, for user not having writing rights
> to /usr/local.

  Well, we don't have to decide where the user will install personal
  modules in is home dir. He should modif the path himself. This is
  at least how it happens on unix systems.

--
Jérôme Marant <jerome@marant.org>
              <jerome.marant@free.fr>

http://marant.org



Reply to: