Bug#941624: Recommending ibus breaks fcitx

[Shengjing Zhu]

On Tue, Mar 2, 2021 at 3:26 AM Andreas Henriksson <andreas at fatal.se> wrote:
>
> 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.

Makes unrelated software on the system (or the whole system) break.

You can't just ignore the existence of tasksel. It's used by the installer.
You can't just break things without coordination.
I'm not maintainer of tasksel. But I'm a member of the input team. And
I don't see it has ever been discussed in the lists.
We can make it better if GNOME maintainer wants to make the ibus
default in a cooperative way, but apparently it's too late in the
Bullseye cycle now.

-- 
Shengjing Zhu