[Pkg-ime-devel] Bug#645729: Bug#645729: Bug#645729: checking for ibus support in gtk2 and gtk3 separately

[Aron Xu]

On Sun, Oct 23, 2011 at 22:41, Osamu Aoki <osamu at debian.org> wrote:
> On Sun, Oct 23, 2011 at 09:52:56PM +0800, Aron Xu wrote:
>> We tried to workaround it in Fcitx by recommending GTK2 IM Module in
>> the GTK3 package, and do the inverse in the GTK2 package. In this
>> case, users are very probably getting both IM Modules installed at the
>> same time, so they can avoid weird misbehavior of installing only one
>> of the two.
>
> Is having dependency loop OK for recommend?  I think this is bad idea.
> See "the circular dependency loop" in recent policy:
>
> http://www.debian.org/doc/debian-policy/ch-relationships.html
> If there is a circular dependency among packages being installed or
> removed, installation or removal order honoring the dependency order is
> impossible, requiring the dependency loop be broken at some point and
> the dependency requirements violated for at least one package. Packages
> involved in circular dependencies may not be able to rely on their
> dependencies being configured before they themselves are configured,
> depending on which side of the break of the circular dependency loop
> they happen to be on. If one of the packages in the loop has no postinst
> script, then the cycle will be broken at that package; this ensures that
> all postinst scripts are run with their dependencies properly configured
> if this is possible. Otherwise the breaking point is arbitrary. Packages
> should therefore avoid circular dependencies where possible,
> particularly if they have postinst scripts.
>
>

You can remove anything that is "Recommend"ed by other packages and
don't need to worry about broken dependencies. APT just _install_
recommended packages, but they are surely _not_ dependencies so it
won't hurt when removing any "Recommend"ed package. On the other side,
the two IM Modules can be installed in any order, so we don't need to
care about postinst scripts for them.

Yes, I know doing this is not the ideal solution, it's a bit tricky
and it *works*. I believe a working input method is better than
nothing, so I recommend ibus to do this as well. When the following
two things being resolved, we can come back to the *ideal* way.

>> To answer your question ultimately, we need to have two things fixed in GTK3:
>> 1.Add a GTK3_IM_MODULE variable.
>
> This needs buy-in from upstream.  Do they support it?  Does it works
> older packages with few updated packages or do we need to recompile many
> packages?
>

I haven't gotten in touch with GTK upstream nor Debian pkg-gnome, and
I don't know about their work flow. I would like to see someone jump
in here to help coordinate with GTK developers and us.

This variable is something great to have. We can specify IM Module for
GTK3 with it so we can ultimately solve the problem when GTK2/3 IM
Modules aren't installed at the same time. During the years with GTK2,
fallback mechanism does not do everything as expected, and now GTK3
does not, either. Thus, relying on the fallback behavior is not a good
choice. An example is QT4, it does not have QT4_IM_MODULE when first
released, but the variable get added eventually.

I've no idea about whether the new variable will work if we don't
recompile the world (this question should be answered by a GTK
expert), but it shouldn't lead to embarrassing results because it
won't cause API/ABI breakage. All in all it's just adding something to
existing ones.

>> 2.Better fallback handling when GTK_IM_MODULE is set but the the
>> specified IM Module does not work or isn't present. It is expected to
>> fallback to XIM when this happens, but currently the fallback does not
>> work at all.
>
> True.
>

--
Regards,
Aron Xu