[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#746578: Reasons to keep systemd-sysv as the first alternative



On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery <rra@debian.org> wrote:
> I conceptually dislike the user experience of switching init systems
> because the user upgraded some random package that, from their
> perspective, doesn't appear related to the init system.  I feel like
> switching init systems should be a more intentional action than that.
> There is a variety of local customization that is init-system-specific,
> and I'm dubious that we're going to be able to catch and warn about all of
> it.
> 
> I've not made up my mind about the merits of switching init systems from
> sysvinit to systemd during a dist-upgrade, but if we do that, I think we
> should do it via some more deliberate and obvious method than pulling
> systemd-sysv in via the dependency tree of some random package.  The
> partial upgrade UX for that is really bad, IMO.

I agree completely that it doesn't make sense for the transition from
sysvinit to systemd to take place via libpam-systemd rather than via
some core package like "init", not least of which because that would
mean systems with desktops or certain daemon packages installed would
get transitioned to systemd but other systems would not.

However, as far as I can tell, I think we've actually solved that
problem: wheezy systems with sysvinit installed will upgrade to the
transitional "sysvinit" package, which depends on "init", which depends
on "systemd-sysv | sysvinit-core | upstart".  Between that and "init"
being "Essential: yes" (which causes apt to try to install it on
all upgrades to jessie), that *should* cause a transition to
systemd-sysv.

Now, that's not quite optimal yet.  Michael Biebl is currently working
on a plan to have fallback boot options available in GRUB that will boot
to sysvinit when both are installed, and that would require having both
systemd-sysv and some sysvinit package (not clear which one) installed.
(This could support other bootloaders as well, and systems not
explicitly covered could still explicitly boot with
init=/lib/sysvinit/init on the kernel command line.)

Nonetheless, as far as I can tell, libpam-systemd is *not* the package
driving the systemd transition anymore.  Does that address your concern,
Russ?

- Josh Triplett


Reply to: