Bug#746577: closed by Michael Biebl <biebl at debian.org> (Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must be coinstallable)

[Martin Pitt]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140506/0a0e19f7/attachment-0005.sig>