On Wed, 14 Aug 2019 at 14:24:26 +0200, Simon Richter wrote: > The long term question remains though -- I dimly remember that we once had > the same discussion about a library pulling in rpcbind, and that made a lot > of people very unhappy at the time.
I think this is a bit of a lose/lose situation: if we downgrade the Depends to Recommends, as long as there is an (IMO unwise) meme that globally disabling Recommends is the right thing to do for "efficient" and "minimal" systems, people will install GTK programs on their desktops with Recommends disabled, and be surprised (and/or open high-severity bugs) when settings aren't saved as a result. libwxgtk3.0-gtk3-dev libwxgtk3.0-gtk3-0v5 libgtk-3-0 None of the dependencies above here can be broken because of how shared libraries work. libgtk-3-common This is an implementation detail of libgtk-3-0, containing its /usr/share. GTK won't work without at least the GSettings schemas (the GSettings API is such that installing the code without the settings schemas is considered to be invalid / a packaging error), so Depends is right. dconf-gsettings-backend | gsettings-backend This dependency is generated by dh_installgsettings as a result of libgtk-3-common containing GSettings schemas. It *could* be downgraded to a Recommends, but then the user of GSettings (in this case GTK) would fall back to the in-memory settings backend, which doesn't actually persist any settings. Not so good. These days there's also a GKeyFile-based backend, which is used inside Flatpak containers; but I think that has problems with multiple writers overwriting each other's changes (like they would tend to for anything else based on a simple text configuration file written by more than one user of a library), which makes it undesirable outside constrained single-app situations like Flatpak. There's also no migration path between that and dconf, so installing dconf-gsettings-backend would result in your previous settings apparently disappearing, which would probably also be considered to be a high-severity bug. dconf-service dconf-gsettings-backend cannot save any settings without the service that deals with change-notification and arbitration between multiple writes (that's how dconf works), so this should probably be a hard dependency. dbus-user-session | dbus-x11 (effectively) dconf is a D-Bus session service which won't work, at all, without a D-Bus session bus. In a more opinionated distro, maybe we would leave out this dependency and just assume that working D-Bus is part of a standard GUI installation (the same way we have that assumption for working X11), but my understanding is that in Debian that would be considered to be a bug (and in a more opinionated distro, we'd probably also have gone for systemd 100%, rather than remaining in a superposition of states). So this needs to be a hard dependency. dbus-user-session is the preferred option on any machine that boots with systemd, because it uses a real service manager, gives the session bus a well-defined lifetime, and works for Wayland, X11 and non-graphical sessions; whereas dbus-x11 (dbus-launch) only works for X11 sessions, results in the dbus-daemon being a child of an arbitrary process with an unpredictable execution environment, and is constrained by the need to avoid breaking assumptions that are not necessarily valid or relevant this decade. libpam-systemd systemd-sysv dbus-user-session relies on `systemd --user`, which needs systemd-logind *and* systemd as pid 1 (a systemd-logind clone like elogind is not enough), so this really is a hard dependency. If someone implements a sufficiently capable non-systemd user-service manager to provide the dbus-user-session semantics without systemd[1], I'd be willing to consider hooking up dbus-user-session to that as an alternative dependency. smcv [1] briefly: one dbus-daemon per "user-session", already listening before ordinary user processes can run, where a user-session is a contiguous overlapping set of login sessions under the same uid (this is the same as the lifetime of XDG_RUNTIME_DIR in the freedesktop.org basedirs specification); and then use the dbus-daemon's socket address "$XDG_RUNTIME_DIR/bus" to set $DBUS_SESSION_BUS_ADDRESS for all ordinary user processes