Bug#941624: Recommending ibus breaks fcitx

[Andreas Henriksson]

Hello Shengjing Zhu,

(FYI I've not been part of pkg-gnome maintenance for the better part of
bullseye development cycle and don't speak for pkg-gnome team, but I
feel this is not a new issue and hopefully my input can hopefully help
shed some light on the situation at hand...)

First let me be clear that IBus is *THE* input method supported by
GNOME. This is not a decision made by or influenced in any way by
pkg-gnome maintainers. The pkg-gnome maintainers simply makes
a judgement call on how to best describe the situation in the form
of package relations.

It is also my previous experience that pkg-gnome team has little to no
influence over how tasksel describes things (and I doubt anything has
changed). You might find it that a third party actually has higher
chance of getting tasksel maintainers to make changes to tasksel if they
discuss it with tasksel maintainers, rather than trying to go via
pkg-gnome team.
My personal best recommendation is to simply not use tasksel!
(And I wish I could have all the time back that I've wasted on
supporting confused users who ended up with problems from using tasksel
over simply using gnome meta-packages. Tasksel simply isn't helpful.)

All the problems you describe to me just sounds like you're describing
tasksel issues. Some specific comments for things you raised below.

On Mon, Mar 01, 2021 at 11:06:53PM +0800, Shengjing Zhu wrote:
[...]
> + Users are now possible to install two input engines. It troubles than benefits.

Bring this up with input engine maintainers. If it's true that having
more than one installed at any time isn't useful, then the solution is
that they all provide a common (virtual) package which they all also
conflict against. Then pulling in one will push out all the others.

This is not related to gnome-shell!

> + And the tasksel won't install corresponding language library for ibus.
> + And for the im-config, it's not possible to decide which engine is preferred
>   by the tasksel data.

Please bring up tasksel issues with tasksel maintainers.

This is not related to gnome-shell!

> Yes you can say that users change it by hand, but it's not
>   what we want to achieve. We want a working desktop for different users by default.
> 
> If GNOME maintainer want to change the default input method, it's better to
> do it in tasksel package.

I don't understand why you think tasksel has any influence over what
GNOME does.... Likely many/most GNOME developers aren't even aware of
tasksel existance. It's an arcane Debian-only program after all.

> 
> Please downgrade ibus to Suggests for bullseye.

It is my personal general reflection that issues like this exists
because debian maintainers tries too hard to be accomodating towards
tweakers which just causes problems and confusion.

As ripping out IBus from under GNOME already requires hacks, I think
it would simply be a better idea to bump to Depends (and tell tweakers
to use equivs). That would hopefully make the situtation less confusing
for people and more obvious that tweakers are on their own with whatever
hack they come up with. Some info already available at:
https://wiki.debian.org/InputMethodBuster

Possibly we could also consider adding (versioned?) Conflicts against
tasksel packages, since there's a long standing disconnect between GNOME
and tasksel meta-package descriptions. To be able to do versioned
conflicts tasksel would first need to have a fixed version though, so
please bring it up with them and then feedback which packages and
versions are relevant to conflict against.

As of right now, this is something I simply consider "wontfix"
from gnome-shells point of view. No matter how the package relationship
is described, the situation that GNOME relies on IBus won't change!

Please also feel free to follow up you severity bump with a
justification pointing out which specific policy paragraph you're
refering to.

Hope this helps. Please also remember that my views are mine and might
not neccessarily reflect the official pkg-gnome standpoint.

Regards,
Andreas Henriksson