Re: Building GTK programs without installing dconf-service?
On Wed, 14 Aug 2019 at 22:53:33 +0200, Jonas Smedegaard wrote:
> Quoting Simon McVittie (2019-08-14 22:20:05)
> > 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."
At least that strong, perhaps stronger. The definition of Depends in
Policy says "required for the depending package to provide a significant
amount of functionality", so GTK's settings probably don't qualify for
that, but application configuration maybe does.
I'm a little surprised that Policy §7.2 doesn't have anything to say
about packages having enough Depends to make the package work correctly,
work as designed or work without data loss, but perhaps that's considered
to be unnecessary, on the principle that Policy doesn't have to enumerate
every possible wrong thing.
> 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.
This is not currently implementable without bypassing dh_installgsettings,
which doesn't currently have any way to add a weaker dependency than
Depends. I'll open a feature request at some point.
The conservative default would be Depends to avoid data loss
(configuration not being stored), but in any case debhelper can't
change its default for this without a compat bump: that would be an
incompatible change, and in particular packages don't normally use the
${misc:Recommends} substvar, so moving from Depends to Recommends without
per-package changes would in practice result in no relationship at all,
which is definitely too weak.
> > 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.
Sorry, this makes a rather less obvious example if you aren't familiar
with the libraries in question...
libgtk-3-0 contains libgdk-3.so.0 (GDK), a lower-level library,
and libgtk-3.so.0 (GTK), a higher-level library that depends on GDK.
Basically all users of these libraries depend on both, either because
they use both or because they only use the higher-level GTK, which depends
on the lower-level GDK itself; that's why the two libraries are combined
into a single binary package.
libgtk-3.so.0 (GTK) has an ELF DT_NEEDED relationship with
libatk-1.0.so.0, but libgdk-3.so.0 (GDK) doesn't.
If a program is linked to libgdk-3.so.0 (GDK) only, it can work without
libatk-1.0.so.0 being installed, so the libgtk-3-0 package does have some
(very niche) functionality without libatk-1.0.so.0. (I am not aware of
any specific programs that genuinely do this.)
If a program is linked to libgtk-3.so.0 (GTK), it cannot work at all
without libatk-1.0.so.0 being installed: ld.so exits with an error before
any user code has the opportunity to run.
I don't think it would be appropriate to weaken libgtk-3-0's
${shlibs:Depends} on the package that contains libatk-1.0.so.0 to a
Recommends, and then respond to the resulting grave bug report by saying
"well, *technically*, you *might* only be using GDK, so a Depends is too
strong", because in practice it's vanishingly rare to depend on GDK but
not GTK, and the failure mode when you depend on GTK but don't have its
library dependencies is that the program doesn't work at all.
(This is not about crashing or segfaulting, and is not about whether you
call particular functions; it's about whether the program can even reach
the beginning of main().)
smcv
Reply to: