On Tue, 05 Dec 2017 at 12:26:43 +0100, Julian Andres Klode wrote:
> More importantly, several packages now require just systemd-sysv. If
> apt is told to install libpam-systemd and such a package in the same
> operation (especially in a chroot I'd say, since that's where neither
> shim nor sysv is installed), it may fail to resolve dependencies
> because it picks systemd-shim first and fails to replace it with
> systemd-sysv later.
Another fun failure mode is that if a dependency chain in a buildd
chroot involves libpam-systemd (the one I experienced today was GTK+ 3
pulling in dconf-service, which depends on a working D-Bus session bus,
and our recommended implementation of one of those depends on systemd),
you'll currently get systemd-shim. This depends on several orphaned or
undermaintained packages, one of which (libnih) uses glibc internal
symbols that make it uninstallable-until-binNMU'd with every new
version of glibc. Again, the current apt resolver commits to installing
systemd-shim and doesn't unwind far enough to be able to replace it with
systemd-sysv when systemd-shim turns out to be uninstallable.
As a general goal, it seems bad to have orphaned packages with no upstream
developer be in the critical path for building unrelated software.
smcv
