Bug#1008493: gnome-control-center and gnome-settings-daemon version mismatch makes keyboard shortcuts fail

[Simon McVittie]

On Tue, 29 Mar 2022 at 12:44:32 -0400, Daniel Kahn Gillmor wrote:
> 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?

Major GNOME components are expected to be upgraded together, except for
when that's unnecessary. That is an unsatisfying answer, but unfortunately
it's the only true answer.

GNOME is intended (by upstream) to be upgraded as a suite of packages that
go together, and we should make sure that each released version of Debian
contains packages that are consistent with each other. Interfaces that
are only intended to be used within the group of GNOME core packages,
and are not intended to be "API" to be used by unrelated software,
will sometimes get incompatible changes.

We find out about incompatible changes within core GNOME components by
reading diffs, or by trying it and seeing what works. We try to set up
appropriate versioned Depends/Breaks to make known-broken situations
impossible to achieve, but in the case of gnome-control-center and
gnome-settings-daemon, we could not proceed with this until the ongoing
python3.10 transition got far enough to make gnome-control-center
buildable again (my upload from yesterday only became buildable today,
after Samba libraries were rebuilt).

If we speculatively added versioned Depends/Breaks even without evidence
of a potentially-incompatible change, then we'd be less likely to see
transient brokenness in unstable, but we'd also be making the overall
system more rigid: we'd be unable to get any of the GNOME 42 core
components into testing until *all* of them were ready to migrate,
which seems like a recipe for making the migration not actually happen
because there's always something blocking it.

I think we need to strike a balance between, at one extreme, having
unstable be so unusable that it is not useful to test, and at the
other extreme, being so conservative about transitions that everything
happens months too late, by which time upstream won't take our patches
or bug reports because they already moved on to the next release cycle
(for example GNOME 40, which didn't reach unstable until GNOME 41 was
already in hard freeze upstream).

The 41 -> 42 transition is more partial than most because Ubuntu want
to ship a mixture of 41 and 42 in their 22.04 LTS release (I'm not 100%
clear on why, I think they want to keep some components on GTK 3 that
would be GTK 4 upstream), and we're being nice to Ubuntu by not upgrading
the components they don't want to upgrade until after their freeze has
reached a sufficiently frozen stage.

> 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.

Sorry, but that normal user probably should not be using unstable.

    smcv