Simon Richter <sjr@debian.org>
wrote:
It's bin:libpam-systemd that pulls bin:systemd-sysv (the package that makes systemd the init on the system), not bin:systemd. Here it's dbus-user-session that pulls it because it needs a logind (dunno if it works with elogind) session opened to have the session bus started when the user logs-in.On 01.12.19 02:54, Russ Allbery wrote: >> Russ> Could you provide some more information about what your >> Russ> concern is here? libsystemd-dev depends only on libsystemd0, >> Russ> which has a pretty tiny list of dependencies and shouldn't >> Russ> require that systemd be running so far as I know. Are you >> Russ> thinking of test suites that assume systemd is available? >> pkg-config for systemd is in systemd not libsystemd-dev > Oh, okay. Also, I remembered some previous discussion that some libraries > end up with dependencies on systemd components for functionality. Thanks, > I think I understand the issue now. That was a thread I started on debian-devel: https://lists.debian.org/debian-devel/2019/08/msg00278.html The resolution of that thread seemed to be that people were mostly fine with the dependency chain because every decision in the path makes sense, even if the end result does not. Without the package pin of systemd-sysv at -100, installing the "libwxgtk3.0-gtk3-dev" package causes an init system switch for me. With the package pin, apt finds no resolution even though one exists (#940965).
So I'm not exactly sure why the systemd.pc should be moved to an
other package.