Quoting Simon McVittie (2019-08-15 20:55:04) > 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.
Stronger than unusual how?
Are you arguing that an installation where in-memory storage of config
is fine is perhaps not an "unusual installation" but a "veeeeery super
dooper weird installations" and therefore does not match Debian Policy
about using Recommends?
Really?
[...]
> > > 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().)
If applications cannot even start without libatk then obviously that's a
dependency (not a recommendation).
Your providing 2 libraries somewhat in concert one with different
requirements than the other seems to me a good case for using a
debian/*.symbols file: Only packages actually linking with GTK gets the
ATK dependency and packages only needing GDK API don't.
- 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
