On 05/05/2014 03:43 PM, Michael Stapelberg wrote: > Hi Zack, > > Fundamentally we agree with you of course. The devil is in the detail, > though: sysvinit-core and systemd are coinstallable, for all the reasons > you explained. > > However, you seem to be using a package which depends on libpam-systemd, > which, translated to English, means the package is using some > functionality that can only be provided when logind is running. To > ensure that logind is running, we had to make libpam-systemd depend on > “systemd-sysv | systemd-shim”. It had to be systemd-sysv to not just > ensure systemd is _present_, but to ensure it is _running_. If we don’t > add this dependency, the package in question is broken, which may well > be the bigger deal to most users than being able to roll back and forth > between init systems :).
I understand this. I contend that, therefore, "systemd-sysv", "sysvinit-core", *and* "systemd-shim" (and "upstart" as well) (quotation marks indicate package names) should *all* be coinstallable; an upgrade from wheezy should install *both* "systemd-sysv" and "systemd-shim" if not already present, and leave "sysvinit-core" installed; and a mechanism independent of package management should control which init brings up the system on the next boot. I did a bit more digging into how it works right now in response to Tolleef's message. First, "systemd-shim" currently doesn't conflict with "systemd-sysv" or "systemd", or vice versa. I don't know how "systemd-shim" works. Does it properly get out of the way if the running PID 1 is in fact systemd? I hope so. If it doesn't, that might be more of a hassle to sort out than anything else. Second, it might simplify matters to split the programs 'telinit', 'halt', 'poweroff', 'reboot', 'runlevel', and 'shutdown', and their manpages, to a separate package shared among all supported init implementations. I observe that if you do install "systemd-sysv" on a system that is currently booted with the /sbin/init from "sysvinit-core", a subsequent 'reboot' still works. Does that mean that /bin/systemctl knows how to talk to sysvinit /sbin/init? Can it do the same for upstart? If so, perhaps the "systemd" package should just take over those programs. If those things are taken care of, then I see no reason why sysvinit-core, systemd, and upstart could not all provide alternatives for /sbin/init, and we'd be done here. zw
signature.asc
Description: OpenPGP digital signature
