Dmitry Bogatov wrote: > [ I am not subscribed. Please keep me in CC. ] [I'm assuming that CCing the various init system @packages.debian.org addresses suffices?]
> Currently, init system packages (sysvinit-core, runit-init, > systemd-sysv) are mutually exclusive -- each of them provides, > among other, /sbin/init file and as such, conflicts with rest. > > This scheme has following drawbacks: > > * switching between init systems is destructive: > once you switch, old /sbin/init is gone; should things go wrong, you > have no easy recover via init=/sbin/old-init kernel option. > > Side note: switching from systemd is more safe, since systemd-sysv > provides only link to /lib/systemd. sysvinit works similarly, with /lib/sysvinit/init. And GRUB has built-in support for these. See /etc/grub.d/10_linux; if you have more than one init system package installed, you will get separate boot options to boot each of the inits that /sbin/init doesn't link to. You might consider submitting a patch to GRUB to add runit to that list, or better yet making that behavior look for symlinks in /lib/inits/ or similar and make an entry for every link that doesn't match /sbin/init. (If you do so with fallbacks to the existing entries for systemd and sysvinit, that'll make a transition simpler, and GRUB can remove the fallbacks as soon as systemd and sysvinit add links in /lib/inits/.) Does that sound reasonable? (Meanwhile, I don't think it's necessarily a good idea to handle /sbin/init and associated programs with alternatives, not least of which because of the complications of switching the running system's init.)
