[Pkg-ime-devel] Bug#645729: Bug#645729: Bug#645729: Bug#645729: checking for ibus support in gtk2 and gtk3 separately
aron at debian.org
Mon Oct 24 15:44:57 UTC 2011
On Mon, Oct 24, 2011 at 21:23, Osamu Aoki <osamu at debian.org> wrote:
> My idea of unidirectional dependency chains for the working input method
> So people install their IM choice package such as ibus-pinyin, then
> complete system comes up. They do not install ibus-gtk first and expect
> ibus-gtk3 and ibus-pinyin to be automatically installed even if it is
> what they need. (If that happen, Japanese, Korean, and chewing users may
> be unhappy) Anyway, language task should list ibus-pinyin like package
> for each pertinent language.
For ibus, this solution looks good. But for Fcitx, the situation
changed a little bit. Every input method engine of fcitx can work for
any frontend, say XIM, IM Modules, and fbterm, so we can't choose to
add a "Recommends" to any of them to ensure the IM Modules get
installed. Otherwise, I have added all IM Modules to Recommends of the
fcitx metapackage, it will be released with next upload.
> I will not strongly oppose to list all reverse direction dependencies as
> "suggest" if you really think this as an important thing to do. This
> may give good guidance if people could not figure out what other
> packages exist to utilize ibus etc. when they want to find out more
> about alternative system setting. But people can find these reverse
> direction dependencies from aptitude anyway. So making such has no real
> gain, IMHO.
>> When the following
>> two things being resolved, we can come back to the *ideal* way.
> Do not you think "recommend" by ibus pointing to ibus-gtk3 enough? It
> just _INSTALL_ ibus-gtk3 by APT.
The ideal solution In my mind is GTK3_IM_MODULE variable get added to
GTK3, which enables us to write hook script to update the
configuration depend on the exact situation.
More information about the Pkg-ime-devel