Re: Building GTK programs without installing dconf-service?
On Wed, 14 Aug 2019 at 20:59:04 +0200, Jonas Smedegaard wrote:
> libgtk-3-0-common could even be relaxed to _suggest_ dconf/gconf since
> already the applications using dconf/gconf declare a dependency on those
> disk-based backends.
The dependency is not because applications store configuration via
GSettings, it is because GTK widgets themselves store configuration (which
is shared between all applications that use those widgets) via GSettings.
The most prominent of these widgets is probably the file chooser
(File -> Open or File -> Save As dialog). Whenever applications use those,
preferences like the sort order are stored via GSettings, even if the
application itself has no mention of GSettings in its source code and
no reason to add a dependency on a GSettings backend on its own behalf.
abiword and audacity are examples of applications that depend on GTK,
probably use file chooser dialogs, but do not depend on a GSettings
backend themselves because they do not use GSettings directly.
The preferences stored in this way are not vitally important, so perhaps
it would be OK for them to just not be propagated outside the application
or stored after it exits (with a warning on stderr) if the GSettings
backend is missing; but it isn't obvious to me that there would be
consensus about that not being a (RC?) bug, which is why I asked.
I suppose one way to represent that in the spirit of what you're saying
would be to drop libgtk-3-0-common's dependency on a GSettings backend,
and make GTK's shlibs/symbols generate a dependency like
libgtk-3-0 (>= x.y), dconf-gsettings-backend | gsettings-backend
instead of just libgtk-3-0? But I don't think that works, because
it would only move the problem up one level, and instead of "I
installed libgtk-3-dev and it pulled in dconf-service", we'd have "I
installed libgtk-vnc-2.0-dev and it pulled in dconf-service" (where
libgtk-vnc-2.0-dev Depends: libgtk-vnc-2.0-0 which is an arbitrarily
chosen library that Depends: libgtk-3-0).
> Issues solely caused by disregarding recommends should be closed as
> not-a-bug indeed.
This is a good rule of thumb, but there must be some point on the scale
between "not required" and "is a hard dependency" where a Recommends
becomes a Depends. If libgtk-3-0 only had a Recommends on libatk1.0-0
(because libgtk-3-0 contains both GDK and GTK, and strictly speaking
you can use GDK without ATK, as long as you don't also link to GTK),
I think there would be consensus that it would be wrong to consider
"libgtk-3-0 should depend on libatk1.0-0" to be not-a-bug.
Obviously failure to store some preferences is less serious than "one
of the two libraries doesn't work at all", but neither is an absolute:
they're both points on a continuum.
smcv
Reply to: