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)

[Zack Weinberg]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140505/08b63c93/attachment-0005.sig>