Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-17 Thread Simon McVittie
On Fri, 17 Sep 2021 at 22:52:45 +0200, Sebastian Ramacher wrote:
> glibc is still not able to migrate, but I have scheduled binNMUs of
> packages involved against the version with the fixed symbols files.
> mutter should be able to migrate in the next run.
> 
> If there are other uploads blocked by glibc and I missed to binNMU them,
> please let me know.

I think gnome-settings-daemon:mipsel and gnome-shell:mipsel would also
benefit from binNMUs:

nmu gnome-settings-daemon_40.0.1-2 gnome-shell_40.4-3 . mipsel . -m 'Rebuild 
against glibc with #994232 fixed'

and while you're there, there seems to be an extension containing
architecture-specific code that isn't critical for the transition but
does need an update for the new Shell, which might as well skip past
glibc as well:

nmu gnome-shell-mailnag_40.0-1 . mipsel . -m 'Rebuild against glibc with 
#994232 fixed'

Thanks,
smcv


signature.asc
Description: PGP signature


Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-17 Thread Sebastian Ramacher
On 2021-09-15 20:09:26 +0200, Sebastian Ramacher wrote:
> On 2021-09-14 09:12:34 +0100, Simon McVittie wrote:
> > On Sun, 12 Sep 2021 at 20:17:36 +0100, Simon McVittie wrote:
> > > According to
> > > https://release.debian.org/transitions/html/auto-upperlimit-gnome-shell.html
> > > it might be necessary to remove
> > > gnome-shell-extension-easyscreencast_1.1.0+git20210116.3252312-1 from
> > > testing if #993061 cannot be fixed soon. The other packages with an upper
> > > limit have already been uploaded to unstable and will hopefully transition
> > > reasonably smoothly.
> > 
> > Looking at the migration excuses for gnome-shell, I think we will need
> > something more like this:
> > 
> > remove gnome-shell-extension-dashtodock/69-1
> > remove gnome-shell-extension-desktop-icons/20.04.0+git20200908-8
> > remove gnome-shell-extension-easyscreencast/1.1.0+git20210116.3252312-1
> 
> Removal hints added
> 
> > 
> > I'm not sure why the first two would block migration since they don't have
> > an upper limit on their version numbers, but those extensions haven't been
> > ported to gnome-shell 40, so they aren't going to work in practice anyway.
> > 
> > Unfortunately this transition has got caught behind glibc, so will likely
> > take a while to migrate. This seems to be a bug in glibc's mipsel symbols
> > file (I'll open a bug for that).
> 
> Thanks. The latest upload of glibc looks like it would soon be able to
> migrate and fixed the symbols file. If there are new regressions that
> prevent migration of some of the ongoing transtions, I will look at some
> additional binNMUs

glibc is still not able to migrate, but I have scheduled binNMUs of
packages involved against the version with the fixed symbols files.
mutter should be able to migrate in the next run.

If there are other uploads blocked by glibc and I missed to binNMU them,
please let me know.

Cheers

> 
> Cheers
> 
> > 
> > smcv
> > 
> 
> -- 
> Sebastian Ramacher



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-15 Thread Sebastian Ramacher
On 2021-09-14 09:12:34 +0100, Simon McVittie wrote:
> On Sun, 12 Sep 2021 at 20:17:36 +0100, Simon McVittie wrote:
> > According to
> > https://release.debian.org/transitions/html/auto-upperlimit-gnome-shell.html
> > it might be necessary to remove
> > gnome-shell-extension-easyscreencast_1.1.0+git20210116.3252312-1 from
> > testing if #993061 cannot be fixed soon. The other packages with an upper
> > limit have already been uploaded to unstable and will hopefully transition
> > reasonably smoothly.
> 
> Looking at the migration excuses for gnome-shell, I think we will need
> something more like this:
> 
> remove gnome-shell-extension-dashtodock/69-1
> remove gnome-shell-extension-desktop-icons/20.04.0+git20200908-8
> remove gnome-shell-extension-easyscreencast/1.1.0+git20210116.3252312-1

Removal hints added

> 
> I'm not sure why the first two would block migration since they don't have
> an upper limit on their version numbers, but those extensions haven't been
> ported to gnome-shell 40, so they aren't going to work in practice anyway.
> 
> Unfortunately this transition has got caught behind glibc, so will likely
> take a while to migrate. This seems to be a bug in glibc's mipsel symbols
> file (I'll open a bug for that).

Thanks. The latest upload of glibc looks like it would soon be able to
migrate and fixed the symbols file. If there are new regressions that
prevent migration of some of the ongoing transtions, I will look at some
additional binNMUs

Cheers

> 
> smcv
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-14 Thread Adrian Bunk
On Tue, Sep 14, 2021 at 09:12:34AM +0100, Simon McVittie wrote:
>...
> Looking at the migration excuses for gnome-shell, I think we will need
> something more like this:
> 
> remove gnome-shell-extension-dashtodock/69-1
> remove gnome-shell-extension-desktop-icons/20.04.0+git20200908-8
> remove gnome-shell-extension-easyscreencast/1.1.0+git20210116.3252312-1
> 
> I'm not sure why the first two would block migration since they don't have
> an upper limit on their version numbers, but those extensions haven't been
> ported to gnome-shell 40, so they aren't going to work in practice anyway.
>...

Package: gnome-shell
Version: 40.4-2
Breaks: ..., gnome-shell-extension-dashtodock (<< 70), 
 gnome-shell-extension-desktop-icons (<< 21.04), ...

> smcv

cu
Adrian



Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-14 Thread Simon McVittie
On Sun, 12 Sep 2021 at 20:17:36 +0100, Simon McVittie wrote:
> According to
> https://release.debian.org/transitions/html/auto-upperlimit-gnome-shell.html
> it might be necessary to remove
> gnome-shell-extension-easyscreencast_1.1.0+git20210116.3252312-1 from
> testing if #993061 cannot be fixed soon. The other packages with an upper
> limit have already been uploaded to unstable and will hopefully transition
> reasonably smoothly.

Looking at the migration excuses for gnome-shell, I think we will need
something more like this:

remove gnome-shell-extension-dashtodock/69-1
remove gnome-shell-extension-desktop-icons/20.04.0+git20200908-8
remove gnome-shell-extension-easyscreencast/1.1.0+git20210116.3252312-1

I'm not sure why the first two would block migration since they don't have
an upper limit on their version numbers, but those extensions haven't been
ported to gnome-shell 40, so they aren't going to work in practice anyway.

Unfortunately this transition has got caught behind glibc, so will likely
take a while to migrate. This seems to be a bug in glibc's mipsel symbols
file (I'll open a bug for that).

smcv



Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-12 Thread Simon McVittie
On Sat, 11 Sep 2021 at 18:29:41 +0100, Simon McVittie wrote:
> On Sat, 11 Sep 2021 at 18:50:05 +0200, Sebastian Ramacher wrote:
> > Unless netatalk is a blocker, let's go ahead with mutter.
> 
> Thanks, I'll start this transition today.

I've uploaded:

- gnome-control-center
- gnome-desktop3
- gnome-remote-desktop
- gnome-settings-daemon
- gnome-shell
- gnome-shell-extensions
- gsettings-desktop-schemas
- mutter

together with various GNOME Shell extensions, and escalated the GNOME shell
extensions' "please be compatible with v40" bugs to serious so that
autoremovals will kick in where appropriate.

As I said earlier, gnome-desktop3 is not, strictly speaking, part of this
transition, but its version number is often used as a proxy for the version
number of GNOME as a whole, so it'll be less confusing for everyone if it
migrates around the same time as the rest of this transition (+/- a week
or two is not a big deal, +/- a month could get confusing).

According to
https://release.debian.org/transitions/html/auto-upperlimit-gnome-shell.html
it might be necessary to remove
gnome-shell-extension-easyscreencast_1.1.0+git20210116.3252312-1 from
testing if #993061 cannot be fixed soon. The other packages with an upper
limit have already been uploaded to unstable and will hopefully transition
reasonably smoothly.

The remaining transitions for GNOME 40 are libgweather (#993934) and
evolution-data-server (#993945). jbicha suggests that after gnome-shell
migrates, we do libgweather next, and finally e-d-s.

smcv



Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-11 Thread Simon McVittie
On Sat, 11 Sep 2021 at 18:50:05 +0200, Sebastian Ramacher wrote:
> On 2021-08-28 11:05:22 +0100, Simon McVittie wrote:
> > I think the transitions for tracker and gnome-shell
> > etc. could probably even happen in parallel, if gnome-shell's
> > dependencies are ready before the tracker transition finishes - they
> > don't seem to collide.
> 
> tracker is almost done (except for netatalk which is blocked by glibc).
> Unless netatalk is a blocker, let's go ahead with mutter.

Thanks, I'll start this transition today.

I don't think netatalk is going to be a problem for the mutter/gnome-shell
transition: I couldn't see any collisions between tracker and mutter, and
netatalk is certainly not closely related to the core GNOME packages.

smcv



Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-11 Thread Sebastian Ramacher
Control: tags -1 confirmed

On 2021-08-28 11:05:22 +0100, Simon McVittie wrote:
> On Sat, 28 Aug 2021 at 05:07:14 -0400, Jeremy Bicha wrote:
> > There is one transition that we could do before gnome-shell and
> > friends and before libgweather: tracker.
> > 
> > I filed https://bugs.debian.org/993052 for the transition. We can take
> > gnome-panel & gnome-applets 41 beta from experimental by reverting the
> > gweather commits to keep the transition unentangled.
> > 
> > I'm suggesting this order for the GNOME 40 transitions:
> > tracker, then gnome-shell & friends, then the libgweather
> > mini-transition, then evolution-data-server
> 
> Makes sense to me. I think the transitions for tracker and gnome-shell
> etc. could probably even happen in parallel, if gnome-shell's
> dependencies are ready before the tracker transition finishes - they
> don't seem to collide.

tracker is almost done (except for netatalk which is blocked by glibc).
Unless netatalk is a blocker, let's go ahead with mutter.

Cheers

> 
> smcv
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-06 Thread Paul Flaherty
Thanks for the information sorry for the misunderstanding.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Simon McVittie 
Sent: Sunday, September 5, 2021 8:09:24 PM
To: Paul Flaherty 
Cc: 992...@bugs.debian.org <992...@bugs.debian.org>; 
debian-gtk-gn...@lists.debian.org 
Subject: Re: Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

On Sun, 05 Sep 2021 at 23:56:23 +, Paul Flaherty wrote:
> I am wondering if we can do a transition on gnome web

I think you are misunderstanding what is being tracked in #992870.

GNOME Web in Debian is the epiphany-browser package, which is already
at version 40 in testing/unstable.

> and also what other
> applications have been transitioned over to gnome 40 and GTK 4

The transition-tracking bug #992870 is about updating core components
of the GNOME desktop itself, in Debian testing/unstable. It is not about
individual applications.

Individual applications are not generally "transitioned over to gnome 40".
GNOME 40 versions of several applications are already in testing/unstable.
Some others are not yet available because they are blocked by separate
library transitions for libgweather and evolution-data-server, but those
are not part of the transition discussed in #992870.

Individual applications can switch from GTK 3 to GTK 4 without needing
coordination with the release team. This requires considerable changes
to happen in each application upstream, and will often take months or
years (some applications still use GTK 2). It does not have to happen
all at once: we can have a mixture of GTK 2, 3 and 4 applications if
necessary.

The only reason why GTK 4 was required for gnome-shell 40 is that one of
the few applications that is already using GTK 4 is gnome-extensions-app,
in the gnome-shell-extension-prefs package.

smcv


Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-05 Thread Simon McVittie
On Sun, 05 Sep 2021 at 23:56:23 +, Paul Flaherty wrote:
> I am wondering if we can do a transition on gnome web

I think you are misunderstanding what is being tracked in #992870.

GNOME Web in Debian is the epiphany-browser package, which is already
at version 40 in testing/unstable.

> and also what other
> applications have been transitioned over to gnome 40 and GTK 4

The transition-tracking bug #992870 is about updating core components
of the GNOME desktop itself, in Debian testing/unstable. It is not about
individual applications.

Individual applications are not generally "transitioned over to gnome 40".
GNOME 40 versions of several applications are already in testing/unstable.
Some others are not yet available because they are blocked by separate
library transitions for libgweather and evolution-data-server, but those
are not part of the transition discussed in #992870.

Individual applications can switch from GTK 3 to GTK 4 without needing
coordination with the release team. This requires considerable changes
to happen in each application upstream, and will often take months or
years (some applications still use GTK 2). It does not have to happen
all at once: we can have a mixture of GTK 2, 3 and 4 applications if
necessary.

The only reason why GTK 4 was required for gnome-shell 40 is that one of
the few applications that is already using GTK 4 is gnome-extensions-app,
in the gnome-shell-extension-prefs package.

smcv



Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-05 Thread Paul Flaherty
I am wondering if we can do a transition on gnome web and also what other 
applications have been transitioned over to gnome 40 and GTK 4.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Simon McVittie 
Sent: Sunday, September 5, 2021 7:47:10 PM
To: 992...@bugs.debian.org <992...@bugs.debian.org>
Cc: debian-gtk-gn...@lists.debian.org 
Subject: Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

Control: tags -1 - moreinfo

I think we're ready for the libmutter-8-0 / gnome-shell transition when
the release team is.

On Sat, 28 Aug 2021 at 13:52:40 +0100, Simon McVittie wrote:
> Non-transition blockers that need to be uploaded in advance:
>
> - wayland-protocols (from experimental, non-GNOME, #992857)
> - pango1.0 (from experimental)
> - gtk4 (from experimental, #992907)

wayland-protocols and pango1.0 are in testing, gtk4 should migrate today.

> Then the libmutter/gnome-shell transition when the release team are
> ready for it:
>
> - gsettings-desktop-schemas (from experimental)
> - gnome-settings-daemon
>   (from experimental, with a patch to decouple it from the libgweather
>   transition which I'm testing now)
> - gnome-control-center (from experimental)
> - mutter (from experimental)
> - gnome-shell
>   (from experimental, with a patch to decouple it from the libgweather
>   transition which I'm testing now)
> - gnome-remote-desktop (from experimental)
> - gnome-shell-extensions (from experimental)
> - budgie-desktop (non-GNOME, from experimental)

All of these are staged in experimental.

> as usual various third-party extensions will need either updating, or
> temporarily removing from testing

The ones I know about are
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fudd.debian.org%2Fcgi-bin%2Fbts-usertags.cgi%3Fuser%3Dpkg-gnome-maintainers%2540lists.alioth.debian.org%26tag%3Dgnome-shell-40data=04%7C01%7C%7Cc7ca50e1fc2e446eab5808d970c80d96%7C84df9e7fe9f640afb435%7C1%7C0%7C637664826785050179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2%2BmEHwAVaTFYaVGz%2BXf4eTfN1s8K2P3OSBgTosLLRjw%3Dreserved=0
(plus a few that I maintain myself, which are fixed in experimental already).

The closed bugs on that list are already fixed in either unstable or
experimental; the ones in experimental will just need a re-upload to unstable.

The packages with unclosed bugs on that list are likely to need temporary
removal from testing to let gnome-shell migrate. A few are probably obsolete
and will go away permanently via RM:RoM:
gnome-shell-extension-remove-dropdown-arrows is the only one I'm aware of
right now.

smcv

--
To unsubscribe, send mail to 992870-unsubscr...@bugs.debian.org.


Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-09-05 Thread Simon McVittie
Control: tags -1 - moreinfo

I think we're ready for the libmutter-8-0 / gnome-shell transition when
the release team is.

On Sat, 28 Aug 2021 at 13:52:40 +0100, Simon McVittie wrote:
> Non-transition blockers that need to be uploaded in advance:
> 
> - wayland-protocols (from experimental, non-GNOME, #992857)
> - pango1.0 (from experimental)
> - gtk4 (from experimental, #992907)

wayland-protocols and pango1.0 are in testing, gtk4 should migrate today.

> Then the libmutter/gnome-shell transition when the release team are
> ready for it:
> 
> - gsettings-desktop-schemas (from experimental)
> - gnome-settings-daemon
>   (from experimental, with a patch to decouple it from the libgweather
>   transition which I'm testing now)
> - gnome-control-center (from experimental)
> - mutter (from experimental)
> - gnome-shell
>   (from experimental, with a patch to decouple it from the libgweather
>   transition which I'm testing now)
> - gnome-remote-desktop (from experimental)
> - gnome-shell-extensions (from experimental)
> - budgie-desktop (non-GNOME, from experimental)

All of these are staged in experimental.

> as usual various third-party extensions will need either updating, or
> temporarily removing from testing

The ones I know about are
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org=gnome-shell-40
(plus a few that I maintain myself, which are fixed in experimental already).

The closed bugs on that list are already fixed in either unstable or
experimental; the ones in experimental will just need a re-upload to unstable.

The packages with unclosed bugs on that list are likely to need temporary
removal from testing to let gnome-shell migrate. A few are probably obsolete
and will go away permanently via RM:RoM:
gnome-shell-extension-remove-dropdown-arrows is the only one I'm aware of
right now.

smcv



Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-08-28 Thread Simon McVittie
On Tue, 24 Aug 2021 at 22:22:48 +0100, Simon McVittie wrote:
> It looks as though we should be able to limit the libmutter-8-0 transition
> to just this cluster of packages.

Almost this.

Non-transition blockers that need to be uploaded in advance:

- wayland-protocols (from experimental, non-GNOME, #992857)
- pango1.0 (from experimental)
- gtk4 (from experimental, #992907)

Then the libmutter/gnome-shell transition when the release team are
ready for it:

- gsettings-desktop-schemas (from experimental)
- gnome-settings-daemon
  (from experimental, with a patch to decouple it from the libgweather
  transition which I'm testing now)
- gnome-control-center (from experimental)
- mutter (from experimental)
- gnome-shell
  (from experimental, with a patch to decouple it from the libgweather
  transition which I'm testing now)
- gnome-remote-desktop (from experimental)
- gnome-shell-extensions (from experimental)
- budgie-desktop (non-GNOME, from experimental)

and as usual various third-party extensions will need either updating, or
temporarily removing from testing (I'm going to upload the ones I maintain
to experimental soon, re-uploads to unstable welcome when the time comes).

smcv



Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-08-28 Thread Simon McVittie
On Sat, 28 Aug 2021 at 05:07:14 -0400, Jeremy Bicha wrote:
> There is one transition that we could do before gnome-shell and
> friends and before libgweather: tracker.
> 
> I filed https://bugs.debian.org/993052 for the transition. We can take
> gnome-panel & gnome-applets 41 beta from experimental by reverting the
> gweather commits to keep the transition unentangled.
> 
> I'm suggesting this order for the GNOME 40 transitions:
> tracker, then gnome-shell & friends, then the libgweather
> mini-transition, then evolution-data-server

Makes sense to me. I think the transitions for tracker and gnome-shell
etc. could probably even happen in parallel, if gnome-shell's
dependencies are ready before the tracker transition finishes - they
don't seem to collide.

smcv



Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-08-28 Thread Jeremy Bicha
There is one transition that we could do before gnome-shell and
friends and before libgweather: tracker.

I filed https://bugs.debian.org/993052 for the transition. We can take
gnome-panel & gnome-applets 41 beta from experimental by reverting the
gweather commits to keep the transition unentangled.

I'm suggesting this order for the GNOME 40 transitions:
tracker, then gnome-shell & friends, then the libgweather
mini-transition, then evolution-data-server

Thanks,
Jeremy Bicha



Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-08-24 Thread Simon McVittie
On Tue, 24 Aug 2021 at 15:23:24 +0100, Simon McVittie wrote:
> Core packages:
> 
> - gsettings-desktop-schemas (must go first)
> - gnome-settings-daemon
> - gnome-control-center
> - mutter
> - gnome-shell
> - gnome-desktop3
> - this one is not strictly versioned, but it'll be less confusing
>   for everyone if we upload it as part of the same transaction
> - budgie-desktop (non-GNOME package, fixed version in Ubuntu but not
>   experimental)

It looks as though we should be able to limit the libmutter-8-0 transition
to just this cluster of packages.

A suitable budgie-desktop version is available in experimental now (kudos
to its maintainer for doing that so quickly).

> Entanglement that I know about so far:
> 
> - libgweather has some sort of incompatible behaviour changes without
>   a SONAME bump. I need to look into this.

What has happened here is that the network services libgweather relies
on are now requiring more info, which the old libgweather literally did
not have available to it. No symbols have been removed from its ABI,
so no SONAME bump; but to actually get weather information, callers now
need to provide an application ID and developer contact info, by setting
properties that previously didn't exist. Additionally, there is an API
(but not ABI) change as a result of one of the network services being
renamed.

It looks as though we should be able to cut the knot by applying some small
patches to gnome-shell (making it provide the new properties if and only if
it sees a new version) and to gnome-settings-daemon (it doesn't use this
part of the API, and its dependency was bumped because it stopped using
now-deprecated functions; we can add a version-check guard).

The new libgweather is still entangled with the new evolution-data-server,
but that can be for someone else to sort out. It's compile-time-compatible
with either version, but is currently forced to use the new version because
we only have one experimental.

smcv



Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

2021-08-24 Thread Simon McVittie
Package: release.debian.org
Severity: normal
Tags: moreinfo
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org

We're heading towards the point where GNOME 40 is ready for unstable.
This involves the usual libmutter transition.

In addition, there have been various functionality moves and other
reshuffles among core GNOME packages. I think it will be best if we
deliberately *avoid* uploading some of the core GNOME packages to unstable
until we are fully ready for the transition.

We are *not* ready for a transition slot yet (hence moreinfo tag),
but I'm opening this bug early so we can mark it with its blockers.

Core packages:

- gsettings-desktop-schemas (must go first)
- gnome-settings-daemon
- gnome-control-center
- mutter
- gnome-shell
- gnome-desktop3
- this one is not strictly versioned, but it'll be less confusing
  for everyone if we upload it as part of the same transaction
- budgie-desktop (non-GNOME package, fixed version in Ubuntu but not
  experimental)

Additionally, libgweather entangles the transition with:

- libgweather (has Breaks on lots of things)
- evolution-data-server :-(
- gnome-applets
- gnome-calendar
- gnome-panel
- gnome-weather
- wmforecast (non-GNOME package, fixed version in experimental)

Entanglement that I know about so far:

- libgweather has some sort of incompatible behaviour changes without
  a SONAME bump. I need to look into this. I hope this part can be
  broken out into a separate transition or something, perhaps by
  backporting support for the new libgweather into old callers or by
  temporarily adding compatibility with the old libgweather to new
  callers, because it links the mutter and evolution-data-server
  transitions and that doesn't seem ideal.

- Many new packages need the new gsettings-desktop-schemas.

- As usual, the new gnome-shell requires the new mutter, while the old
  gnome-shell requires the old mutter. We have to do this part in lockstep.

- GNOME Shell has changed its workspace layout from vertical to horizontal,
  and the default keybindings in gsettings-desktop-schemas have changed
  Super+PgUp, Super+PgDn to match. The new default keybindings will make
  no sense for the old Shell. I don't think this is necessarily important
  enough to need a Depends/Breaks, but we should minimize the time that
  this situation exists for.

- Mouse settings have moved from gnome-settings-daemon to
  gsettings-desktop-schemas. If we have the new g-s-d and the old g-d-s,
  things will still technically work, but gnome-tweaks will seem broken
  (because it's using the new settings that the old g-s-d ignores).

- Responsibility for audible feedback when taking a screenshot moved from
  gnome-settings-daemon to gnome-shell. Again, this isn't important enough
  to need Depends/Breaks, but we should minimize the skew.

- gnome-control-center configures all the other core packages so its
  version should not diverge.

Ben file for the mutter transition, which is the key thing here:

title = "mutter";
is_affected = .depends ~ "libmutter-7-0" | .depends ~ "libmutter-8-0";
is_good = .depends ~ "libmutter-8-0";
is_bad = .depends ~ "libmutter-7-0";