printer-driver-postscript-hp Depends: hplip
hplip Depends: policykit-1
policykit-1 Depends: libpam-systemd
libpam-systemd Depends: systemd (= 204-14)
Since the last in the above is a versioned dependency, that means you can't use systemd-shim to satisfy this dependency.
I do think we should migrate to systemd. However, it's unfortunate that this change is being rushed like this. I want to migrate my personal laptop to systemd—but not before I have the time to deal with any fallout that might result, and to make sure I can properly migrate my configuration.
Workaround (for now): hold policykit-1 at 0.105-3 rather than have it upgrade to 0.105-6. That version doesn't have a dependency on libpam-systemd.
Off-hand questions:
- Why does one need to log in to an init system? (yes, yes, it's probably a session PAM module, not an auth or password module. Still)
- What does policykit do that can't be solved with proper use of Unix domain sockets and plain old unix groups?
All this feels like another case of overengineering, like most of the *Kit thingies.
Update: so the systemd package doesn't actually cause systemd to
be run, there are other packages that do that, and systemd-shim can be
installed. I misread things. Of course, the package name is somewhat
confusing... but that's no excuse.
The systemd binary package doesn't affect your init system. All it does is provide some related systemd binaries that other packages may use.
The part of the dependency chain that you're concerned about is
libpam-systemd Depends: systemd-sysv | systemd-shim. As you can see, this still allows you to stay with sysvinit as the init system but provide the logind API that is required via systemd-shim.What does policykit do that can't be solved with proper use of Unix domain sockets and plain old unix groups?
PolicyKit answers questions like "can this user open the audio device?" For many of such questions, it is desirable to be able to answer yes if the user is logging in locally, and no if remotely. Previously, PolicyKit used ConsoleKit to answer such questions, but ConsoleKit has been abandoned upstream, so now PK relies on systemd-logind.
Why does one need to log in to an init system?
Because, besides answering questions like the above, it can manage user sessions in ways that go beyond doing stuff on login. For example, it is rumoured that systemd (at some version not yet available in debian) can start a single dbus instance for all user logins. This means you could use dbus-using programs easily on a VT. Or you could have a working pulseaudio on a VT as well. Or many other things I have not yet thought of
AFAICT, libpam-systemd isn't for the init-system-part of systemd, but for logind.
How about limiting certain operations to users that are logged in on a physical terminal (and not via ssh, vnc, etc.)? E.g. only the user who plugged in a flash drive (i.e. the one who has an open physical session) can read and modify its contents.