On Thu, 04 Jan 2018 at 04:36:16 +0100, Adam Borowski wrote: > * utopia stack (policykit and friends) which have a hard dependency on > systemd
policykit-1 depends on libpam-systemd, which is currently how you spell "requires a working systemd-logind" in Debian dependencies. systemd-logind is part of systemd.deb, and requires something that looks a bit like systemd, either the real systemd as pid 1 or systemd-shim. > * dependencies on libpam-systemd (including "mere" Recommends, which make > apt force an init switch or abort an upgrade without a workaround obvious > to an user who doesn't know what to look for) Many of these are more about having a working systemd-logind (an improved ConsoleKit replacement) than they are about having systemd as pid 1: they need to be able to identify and enumerate user sessions, and match processes to sessions. If there's a good alternative to systemd-logind for that purpose, they could talk to that instead. It looks as though elogind is a fork of systemd-logind with reduced functionality, no dependency on systemd as pid 1, and logind's D-Bus API (so, basically systemd-shim done right), so it should be possible for most of those to talk to elogind's logind-compatible API without code changes (via libsystemd, even). Now that we have versioned Provides, one way to achieve that might be for implementations of the logind API to add Provides: logind (= v) where v is the version of systemd whose logind API is implemented (currently 219 for elogind and 236 for systemd), and for depending packages to depend on libpam-systemd (>= v) | logind (>= v), or even on default-logind | logind (>= v) (with default-logind provided by libpam-systemd on Debian) to be nice to anti-systemd derivatives. Obviously >= v can be omitted if recent logind features are not required. A few packages do genuinely need systemd as pid 1, or `systemd --user` as an init-like service manager for user sessions (which in turn requires both systemd as pid 1 and systemd-logind). dbus-user-session is an example of a package that requires the `systemd --user` service manager. Packages in this category are unlikely to be ported to not-systemd, unless the chosen non-systemd infrastructure grows a lot of functionality that is basically systemd with the bike shed painted a different colour. smcv