On Fri, Mar 07, 2003 at 01:54:10PM +0100, Jérôme Marant wrote: > En réponse à Sven Luther <[EMAIL PROTECTED]>: > > > > 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.
Well, but if they screw up, to bad for them, and if they complain, i simply ask them to rerun the wrapper-script. With prominent notice about this in the README.Debian and maybe even a debconf note, it should be ok. > > 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-*. This is the step i want to avoid. Friendly, Sven Luther
