Quoting Simon McVittie (2019-08-14 22:20:05) > 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.
Ah, thanks for pointing that out. > 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. Would it be fair to describe both widget and application needs for file-based config backend as required in "all but unusual installations." > 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). No, I don't mean that libgtk-3-0 should tell all its consumers that they all should depend(!) on a file-based config backend. I simply noticed that a bunch of applications currently declare a dependency on those backends, without knowing how they grew that package relationship. Based on your enlightening me above, I'd say that libgtk-3-0 should recommend those backends, and consumers of the config API provided by libgtk-3-0 should also (ideally only by default, possible to relax/tighten by each concrete package) recommend those backends as well. > > 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. Not sure I follow you above. If an application links with libgtk-3-0, If libgtk-3-0 provides an API that links with both GDK and ATK and gracefully handles consumers calling the ATK-related parts while libatk is missing, then libgtk-3-0 should only recommend libatk. If however using the parts of libgtk-3-0 API related to ATK causes the library to segfault if libatk is missing, then libgtk-3-0 should depend on libatk. Or are you talking about some other kind of behaviour? > 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. Question is not if a feature totally stops working when related package is missing but instead if said feature truly is optional by _any_ extend - i.e. is there some exotic situation where it is sensible to omit without causing the code to become unstable? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
