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
