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 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918153431.GA14232@thin