This libsystemd points to a dangerous habit of the certain group of developers who prefer strong interdependency and monolithic architecture. In similar way, you have libdbus which is technically not the actual dbus, but tries anything to launch dbus processes if loaded and initialized as a library. And gconf libraries which ship daemon executables and also launch daemons from library. Libsystemd is apparently not doing such right now, but given its windows.dll like nature, it's a reasonable concern to have.
> In similar way, you have libdbus which is technically not the actual dbus, but tries anything to launch dbus processes if loaded and initialized as a library.
That can only happen if the dbus executables are installed; libdbus-1-3 Recommends but does not Depend on dbus. This is the standard way of things for everything in Debian, and the dbus packaging is no different from the Kerberos packaging here.
As I mentioned, it would be in violation of the tech-ctte ruling if depending on libsystemd0 also brought in systemd itself as a hard dependency.
> it's a reasonable concern to have.
The entire worldview of systemd is that you shouldn't be spawning things from your current environment (cf. daemonizing in /etc/init.d/foo), you should ask some parent keeper process to spawn the executable. It sounds like it would involve systemd doing the exact opposite of what it currently does if libsystemd were to fork-and-exec much of anything.
For instance, systemd is obsoleting the setuid dbus-daemon-launch-helper, which I am super excited about, having gotten on dbus-daemon-launch-helper's bad side far too many times.
