Gustavo Noronha Silva wrote: > Em Sun, 8 Oct 2006 18:56:39 +0200 > Hendrik Sattler <email@example.com> escreveu: > >>> The various commands you said could be provided as slaves to >>> the /sbin/init alternative, which will make them be switched >>> 'atomically'. >> But you need the shutdown command for the running init, not for the >> chosen-for-next-boot one. > > I see... maybe upstart's shutdown could be hacked to detect it is > running in a sysvinit booted system, and call its binary, if so. > Something along these lines is what module-init-tools have been doing > for sometime now, IIRC. This is actually not necessary. Atm the upstart package Conflicts/Replaces: sysvinit. This way the sysvinit package is uninstalled upon installation of sysvinit. Upstart's reboot/halt/shutdown/poweroff commands can deal with a running sysv init and a controlled shutdown or reboot is possible. We don't really need the ability to install *multiple* init systems in parallel imho , rather than make it actually possible to install an *alternative* init system (replacing sysvinit), which is currently cumbersome because of sysvinit's Essential tag. As we can't remove the Essential tag from sysvinit for etch anymore, aj proposed to use an alternative/diversion to work around this problem (meaning, sysvinit doesn't need to be uninstalled). At least this is how I understood him, I hope he corrects me, if I misinterpreted him ;-) To repeat myself, the cleanest and simplest  solution is to remove the Essential flag from sysvinit as outlined in my first post. Let's see if we can do that for etch+1. Cheers, Michael  A dbms or something alike is different, because you potentially have to transfer data from the old to the new system.  The most simple approach is mostly the least error prone. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Description: OpenPGP digital signature