Bug#746578: Reasons to keep systemd-sysv as the first alternative
I'd like to call attention to a few reasons why libpam-systemd should
continue to depend on "systemd-sysv | systemd-shim".
First, see bugs like 761389 (and others on cgmanager and systemd-shim),
which are still popping up regularly. While I acknowledge that people
are actively working on the shim stack, far fewer people work on or test
that stack (or have a reason to care about that stack) than on the
systemd stack, and that stack is continuously playing catch-up based on
new systemd development. As a result, it will inevitably encounter more
issues than the systemd stack. That's not an argument to drop that
stack, but it *is* an argument to not make it the default. I don't
think it's reasonable to consider the shim stack a more "natural" change
from sysvinit; people argue for sysvinit based on legacy/maturity/etc,
but the shim stack introduces a significant amount of new machinery
with far *less* maturity, legacy, or testing than sysvinit *or* systemd.
Second, the technical committee *already* decided to make systemd the
default init system. This seems like yet another attempt to seize an
opportunity to erode or undermine that decision. (I anticipate many
more such attempts in the future.) The technical committee decision did
not say "default only for new installs, with upgrades using sysvinit",
for instance.
Third, there's already a proposal on -devel to detect potentially
problematic situations on upgrade (such as hand-edited /etc/init.d
scripts that would be superseded by un-edited .service files), and
prompt in that situation. Such a prompt would be similar to the
existing prompts obtained when attempting to remove the package for the
running kernel; they're not the most elegant approach around, but they'd
address many of the concerns regarding more intricate sysvinit setups
that would need manual intervention for a smooth upgrade. That would
then avoid introducing a prompt for *all* systems, even those that can
smoothly upgrade with no issues.
I would advocate for implementing the prompting proposal, and keeping
systemd-sysv as the first (preferred) alternative in libpam-systemd's
dependencies.
(Though, if a one-time unconditional prompt about upgrading to systemd
would serve as suitable warning, I'd advocate for that; however, somehow
I doubt that step would actually satisfy people calling for systemd's
head.)
- Josh Triplett
Reply to: