Re: Building GTK programs without installing dconf-service?
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
Reply to: