On Mon 2022-03-28 21:26:16 -0400, Jeremy Bicha wrote: > This fix is pending
Thanks for the pending fix, Jeremy. I can't help noticing that this
failure looks like a classic backward-incompatible API change. The API
happens to be across a gsettings schema instead of a C library,
language-specific module, or network service, but it's still the same
thing.
As a community, we have decades of hard-won experience in reasoning
about and handling API changes: thinking about what kinds of changes are
backward-compatible (adding interfaces) or backward-incompatible
(removing or changing interfaces), how to signal them (SONAMEs for C
shared objects, libtool's current/revision/age, semver in many of the
modern language ecosystems, URL prefixes for HTTP REST, etc), and how to
declare dependencies on them in ways that are not hard to propagate into
downstream package managers.
How does GNOME track these API changes across its constitutent projects?
I'm too much of a newbie in GNOME to know how that's done, but if there
is some sort of API version tracking within gnome, then it seems like
either gnome-settings-daemon should have marked a backward-incompatible
API bump when it removed the "screenshot" key from the schema or
gnome-control-center didn't accurately specify its particular API needs
from gnome-settings-daemon. If that signalling is present, and either
of those were fixed upstream, that knowledge should be propagated to the
debian packaging.
If there is no explicit API dependency tracking within GNOME, but
version numbers of major GNOME components are supposed to advance in
lockstep, then shouldn't the corresponding packages in debian have
automated and explicit dependency annotations to enforce that lockstep
transition?
There are other options too, of course, including:
- gnome-settings-daemon could declare that any given key in its schema
could go away, and expect callers to deal with such an outage. In
that case, gnome-control-center is at fault for aborting when the
'screenshot' key was not found.
- gnome-settings-daemon could avoid a backward-incompatible API change
by retaining the "screenshot" key, possibly emitting deprecation
warnings somewhere when the deprecated key is accessed. Some future
version could bundle a collection of schema removals into a larger
backward-incompatible API change after a suitable deprecation window.
This is a larger general concern about the health of GNOME in Debian
going forward: i don't expect the GNOME interdependencies to get simpler
over time (what user-facing software does?), so i would like to
understand how GNOME and the Debian GNOME team think about handling them
in general.
GNOME typically does a good job in handling a novice user's behaviors
well without hassling them with confusing technical arcana, but that
means that silent and complete crashes like the one observed here just
look like unrecoverable breakage to the normal user who doesn't know
anything about stderr or how to launch settings from the terminal.
If you think this is an upstream GNOME issue and no debian-specific at
all, I'm happy to move this off the Debian BTS, just tell me where you
think the appropriate venue is.
Thanks for your work maintaining GNOME in debian!
--dkg
signature.asc
Description: PGP signature
