Bas Wijnen wrote: > On my system, I see systemd-sysv being pulled in by libpam-systemd, which is > required by network-manager and policykit-1. > > libpam-systemd will accept systemd-shim instead of systemd-sysv as well, but > it's listed later, so the user has to manually select it if they want to keep > their init system. In a long list of "this needs to be changed to make the > upgrade work", it's very easy to miss that it happens at all, and even if a > user does see it, I don't think we can expect them to understand what it > means, > and go check if there is an alternative. > > I think it would be good for libpam-systemd to list systemd-shim first. That > way, installations that already have systemd for some other reason (like it > being the default from d-i) will still work, but it won't switch existing > installations to a new init system unexpectedly.
Having libpam-systemd depend on "systemd-shim | systemd-sysv" will not properly handle systems that already have systemd installed but not systemd-sysv. > That being said, I don't really care much about the init system; sysv worked > fine for me, and now I apparently have systemd and it doesn't seem to cause > problems either. Given the lack of a massive number of new bug reports against either systemd packages or the desktop packages depending on them, I suspect that's the general result, as well: uneventful upgrade to a system that's still sysvinit-compatible, where we can deal with bugs as they come up. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140512161727.GA5829@jtriplet-mobl1