On Wed, 14.07.10 15:26, Bill Nottingham (notting@xxxxxxxxxx) wrote: > > Lennart Poettering (mzerqung@xxxxxxxxxxx) said: > > > Would alternatives work here ? > > > > Yes, the alternatives system would probably work. However, I think there > > are things where it is a good idea to use and where it isn't. And I > > think this case is one of the latter. If we go down the switchable init > > via symlinks route then i'd prefer if we did this via > > installing/removing packages, not via the alternatives system. > > alternatives isn't really appropriate - it's only changeable at runtime, > which means that you'd flip the alternative, and then telinit/shutdown/etc > would all start acting strangely w.r.t. the init you're currently running. I think this is actually not that big of a problem. The systemd client tools actually can speak /dev/initctl as well as the Upstart D-Bus API too a limited degree. Also, the Upstart client tools actually speak /dev/initctl too, to some degree. This is needed to facility upgrades properly. Also note that systemd actually supports /dev/initctl. Here's a little chart showing you which client tools (x) speak which protocol (y): sysvinit | Upstart | systemd ---------+---------+-------- /dev/initctl fully | limited | limited Upstart Proto | fully | limited Systemd Proto | | fully And here's the same table showing which init daemons speak which protocol (i.e. which proto is supported on the server side): sysvinit | Upstart | systemd ---------+---------+-------- /dev/initctl fully | | limited Upstart Proto | fully | Systemd Proto | | fully The effect of this is that the upstart client tools can speak to all three init systems either via /dev/initctl or via native Upstart. And also the systemd client tools can speak to all three init systems too, via any of the three protocols. "limited" in this context usually means that it is enough to reboot the system or change a runlevel (or something equivalent). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel