Re: fix the world, make it a better place ...
En réponse à Sven Luther <luther@dpt-info.u-strasbg.fr>:
> > For example, imagine a mess with gcc pointing to gcc-2.95 and
> > g++ pointing to g++-3.2.
>
> Ok, i don't believe this would be such a problem, but anyway, that is
> why i was thinking of doing a version changing script, which would
> wrap
> all the update-alternative calls. This way, the user would only have
> to
> call switch_ocaml <version_number> and automatically the right
> alternatives for the <version_number> version of ocaml would be
> choosen,
> It would be nicer if update_alternative supported alternative
> meta-packages or something such though.
As long as there are alternatives in the package, even wrapped
like in the postinst, they are risks. And usually people do not
change simple symlinks.
> > This is the reason why the symlink solution without alternative
> > is not used in gcc, for example.
>
> Err, i think you wanted to say that is why gcc don't use alternatives
> but simple symlinks ?
Yes, I mistyped.
> > > > Let's do it like Python.
> > >
> > > How does python do it ?
> >
> > Only the greatest version of Python provides the emacs package.
> > It is unversioned.
>
> Mmm, ok. But the idea was _not_ to rebuild older versions of ocaml
> when
> i upload the new one. Let me think more about it.
Here is the way Python transitions happen.
- The greatest Python say X, provides pythonX-* packages and
dummy packages python-* pointing to pythonX-*.
- a new PythonX+1 is being uploaded
- everyone make PythonX+1 standard in their package
- PythonX is rebuilt and uploaded without the python-x dummy
packages. It is not a problem since dummy packages are still
on users system and still point to pythonX-*.
- PythonX+1 is reuploaded and now provide python-* dummy
packages
Cheers,
--------------
Jérôme Marant <jerome.marant@free.fr>
Reply to: