Bug#1115532: libgtk-4-1: compose and dead keys not working anymore on wayland

[Simon McVittie]

On Thu, 04 Dec 2025 at 15:09:58 -0500, Jeremy Bícha wrote:
>Simon, do you have any thoughts on what we should do here?
>
>I have added Depends: ibus to gnome-core today. Maybe I should add
>Depends: ibus-gtk4 there too.

I think a Depends or Recommends from gnome-core to ibus-gtk4 (and 
perhaps ibus-gtk3 as well) would make a lot of sense.

>gnome-shell has Recommends: ibus
>ibus has Recommends: gtk4

(More precisely, ibus has Recommends: ibus-gtk4, ibus-gtk3, and their 
GTK 2 equivalent ibus-gtk)

>libgtk-4-1 doesn't have any dependency relationship on ibus.
>Historically, we would have hesitated to have libgtk-4-1 depend on
>ibus-gtk4 because of concerns about circular dependencies.

I think *if* we can continue to make ibus-gtk4 not have any dependency 
relationship on libgtk-4-1, then it would be reasonable to make 
libgtk-4-1 Recommends ibus-gtk4. I think a Depends would be too strong, 
because it's entirely possible to use GTK with a different input method 
like FCITX, or no input method at all.

GTK 3 and even GTK 2 could get the same treatment (and so could Clutter, 
if we weren't trying to remove it already).

*After* each GTK version Recommends the corresponding ibus plugin, we 
could also consider relaxing ibus' Recommends on the GTK ibus plugins to 
be a Suggests, or removing it completely and relying on GTK to pull in 
appropriate plugins to use ibus. I think it would certainly make sense 
to drop ibus' Recommends on ibus-gtk down to a Suggests or no 
relationship at all, even if the other two stay as Recommends.

So we would have something like this, with all the dependency arrows 
in the graph flowing one way, and no cycles:

              {-D-> ibus -R/S?------------------->}
metapackages {                                   } ibus-gtk4
              {-D-> GTK4 apps -D-> libgtk-4-1 -R->}

              {-D-> ibus -R/S?------------------------>}
metapackages {                                        } ibus-gtk3
              {-D-> GTK3 apps -D-> libgtk-3-0t64 -R--->}

GTK2 apps -D-> libgtk2.0-0t64 -R->}
                                   } ibus-gtk
                          ibus -S->}

>I'm not
>very sure what the problem with circular dependencies is; maybe it's
>mostly a problem for bootstrapping?

Partly it's a problem for bootstrapping and minimal build and/or test 
environments: the GTK -dev package depends on the shared library, so if 
the shared library depends on something that can only be compiled by 
using the -dev package, we have a bootstrapping problem. Demoting a 
Depends to a Recommends solves this, because buildds don't install 
Recommends, and developers don't strictly need to install Recommends 
either.

Partly it's an installation problem: if there's a cyclic dependency 
between packages that have a postinst, apt cannot implement the Policy 
guarantee for Depends. For example if libgtk-4-1 Depends ibus-gtk4 and 
ibus-gtk4 Depends libgtk-4-1, Policy says apt must call "dpkg 
--configure libgtk-4-1" before "dpkg --configure ibus-gtk4", but Policy 
also says apt must do the opposite, and that isn't possible. apt will 
resolve this by breaking the cycle in an unpredictable place, which is 
out-of-spec behaviour (a Policy violation) that is difficult to reason 
about. Demoting a Depends to a Recommends (or less) solves this, by 
telling apt: *this* is an acceptable place to break the cycle.

And partly it's a cleanup problem: if a user of a non-GTK-based desktop 
like KDE Plasma installs a single GTK 4 app (let's say quadrapassel), 
then decides that actually they don't like this app and removes it 
again, apt will not automatically clean up the unused libgtk-4-1 and 
ibus-gtk4 if they have a circular Depends or even Recommends on each 
other: libgtk-4-1 would be kept because ibus-gtk4 depends on it, and 
ibus-gtk4 would be kept because libgtk-4-1 depends on it. Demoting a 
Depends to a Recommends is not a solution for this, but demoting a 
Depends or Recommends to a Suggests solves it.

>Related to our multi-year drive to not install gtk2 by default or in
>more places than necessary, ibus-gtk4 has a dh_shlibdeps override to
>avoid a direct dependency on libgtk-4-1. That may not have been
>necessary for gtk4

It's unnecessary *if* we make sure that libgtk-4-1 *doesn't* get a 
Recommends or Depends on ibus-gtk4, but what I'm suggesting above is 
that libgtk-4-1 Recommends ibus-gtk4 could be a good solution.

I think having this dh_shlibdeps override is a good thing in general: it 
was necessary for GTK 2, it will be necessary for GTK 3 when we start 
phasing it out in favour of GTK 4 or newer, and it will presumably be 
necessary for GTK 4 in a few years' time. It also gives us more options 
when it comes to how we avoid cyclic dependencies and cyclic Recommends.

Ideally src:ibus could have an autopkgtest (or even a build-time check) 
that inspects the Depends and Recommends of ibus-gtk{,3,4} and asserts 
that they don't match /libgtk/? That would have caught the regressions we 
saw for this mechanism during the t64 transition.

>maybe we're far enough along that ibus' gtk2
>support could be removed now

A step in that direction would be to weaken ibus' Recommends: ibus-gtk 
to a Suggests, or remove it completely. That way, ibus will still 
require GTK 2 at build time, but will not install anything GTK 2 by 
default at runtime.

     smcv