Zack Weinberg [2014-05-05 20:29 -0400]: > 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.
Isn't the "sysvinit" package now meant to provide this "selector"? I don't know if it's debconfified or similar, but having such a selector package was the reason for moving the old sysvinit to s-core, wasn't it? > 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? Yes, it does, that's how it was designed. It provides a D-BUS activatable, and heavily reduced, interface for things like suspend or setting the time zone. But if you run the "real" systemd, those D-BUS objects already exists, and thus the D-BUS .service file is entirely ignored. > 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. Would that actually work? I thought that the implementation of these depended on the current init system in use? At least when I tried to move from upstart to sysvinit on a fresh vserver that I got recently, all these (reboot, etc.) were broken. Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
