Bug#886182: transition: glibc 2.26
On Thu, 04 Jan 2018 at 21:52:32 +0100, Michael Biebl wrote:
> Am 04.01.2018 um 20:05 schrieb Simon McVittie:
> > (In particular, I'm trying to release ostree to fix a RC bug, but it now
> > fails to build due to a hilarious dependency chain involving
> > gjs -> libgtk-3-0 -> dconf-gsettings-backend -> dconf-service ->
> > dbus-user-session -> libpam-systemd -> systemd-shim -> cgmanager -> libnih1
> > due to CTTE decision #746578 preferring systemd-shim over systemd-sysv.)
>
> See related #883573.
> Fwiw, after pondering about this for a while, I consider dropping the
> Depends: systemd-shim | systemd-sysv
> from libpam-systemd altogether.
This would result in there being no way for a package to declare "I need
a working systemd-logind" and get the relevant packages installed, which
seems like a regression. If people who don't like systemd as pid 1 get
round to packaging elogind (a fork of logind with reduced functionality
and no systemd dependency), then we'd need a virtual package or something
anyway, but until then libpam-systemd is the official way to declare
that dependency.
> So for the few users who actually want to use sysvinit + a
> full blown desktop I would leave it up to them to install systemd-shim
> manually.
I don't think it's a desirable outcome for those users to be filing RC
bugs of the form "gnome-control-center: missing dependencies",
particularly when systemd-related issues make everyone extra-adversarial.
> This would also avoid pulling an init system for packages
> which build-depend on dbus for dbus-run-session (which would also fix
> your particular problem)
I feel as though something is wrong in this dependency chain, but
I'm not sure what - most of the dependencies are defensible. Perhaps
libgtk-3-common should only have a Recommends on dconf-gsettings-backend,
as part of the principle that libraries don't generally hard-depend
on services? (But that would require modifying dh_installgsettings.)
> I'd be happy to make a systemd upload dropping this dependency to
> unblock ostree.
I've turned off the tests that use gjs for now, and I'll probably
propose a patch upstream to make it possible to package the JS
installed-tests without having gjs present at build-time.
smcv
Reply to: