[Pkg-ime-devel] Bug#704705: Bug#704705: ibus: cannot use with both Mozilla i386 apps and emacs

Sat Apr 6 12:35:33 UTC 2013

On Sat, Apr 6, 2013 at 2:54 PM, Osamu Aoki <osamu at debian.org> wrote:
> Hi,
>
> Thanks for investigating this.  I did similar.
>
> My conclusion:
>  * ibus-gtk:i386  issue is possibly user issue with downgrade.
>  * ibus-gtk3:i386 issue is possibly user issue with downgrade.
>  * ibus-qt4:i386  issue is the issue of libibus-qt1 not being multiarch.
>
> So this is not bug with ibus.
>
> Here is what I did tracing your comment.  Without your proof of
> co-installed ibus-gtk:i386 and ibus-gtk:amd64 etc., I was poking wrong
> things.  Thanks.
>
> On Fri, Apr 05, 2013 at 04:58:22PM +0200, Toni Mueller wrote:
>>
>> Hi Osamu,
>>
>> On Fri, Apr 05, 2013 at 11:07:19PM +0900, Osamu Aoki wrote:
>> > Multiarch is well defined and implemented for libraries but for these
>> > executables used by other software, the best practice was not clear to
>> > me and may had some wrong handling.
>
> (I did think a lot on this but its been more than 6 months.  My memory
> is vague.  So I need to check everything again.)
>
>> I now have several of the library packages installed in parallel,
>> so it seems to work, after all. But in the process of converting my
>> machine, I found that often, installing one version would sort of kill
>> the other, and from my perspective, it's more of a hit-and-miss
>> experience, whether two instances of a library can be installed, or not,
>> and I apparently got tripped up over that. :/
>>
>> > ibus being "Multi-Arch: foreign" it can serve both i386 and amd64
>> > applications by either one of ibus:i386 and ibus:amd64 but ibus:i386 and
>> > ibus:amd64 are not co-installable.
>
> But as I re-think ibus:i386 and ibus:amd64 should be co-installable. I
> should have said the previous following text as the following instead.
>
> ibus-gtk:i386 run-time support programs and co-installable because it is "Multi-Arch: same".
> ibus-gtk:amd64 run-time support programs and co-installable because it is "Multi-Arch: same".
>

AFAIK, ibus:i386 and ibus:amd64 should not be co-installable.

The story for input method framework's Multiarch support is that, only
one input method framework run at a time, thus if you use amd64 more
then you install an amd64 version of ibus, including engines like
anthy, hangul, and pinyin, and also ibus-table-*. IM Modules are
run-time plugins to UI toolkit, so they must be co-installable, so if
you have GTK+ of both amd64 and i386, then you need both of the IM
Modules. The IM Modules should communicate with the core framework
using sockets, dbus, or something likewise, and the communication
should not be architecture-specific.  In this way can we accomplish
Multiarch support of input method frameworks.

> So there should be some reason why these were not co-installable here.
>
>> To wit, I now have, excluding tables-* etc:
>
> Oh great but what are the  tables-*.  I guess you mean ibus-table-*.
> but .. wait ...
>
>  [2011-12-26] Accepted 1.3.0.20100528-3 in unstable (low) (Osamu Aoki)
>
> ibus-table-others (1.3.0.20100528-3) unstable; urgency=low
>
>    * Move to utils section. Closes: #646673
>    * Convert to dh syntax and update package description.
>    * Remove non-ASCII keys. Closes: #653216
>  -- Osamu Aoki <osamu at debian.org>  Sun, 25 Dec 2011 20:12:41 +0900
>
> No multiarch updates were done by me but these are Architecture: all packages.
>
> So this problem can not be caused by ibus-tables-*.  What is going
> on....
>

I think there is no need for ibus-table-* to be Multiarch because the
reason I said above.

>> ii  ibus-gtk:amd64                                    1.5.1.is.1.4.2-1                   amd64        Intelligent Input Bus - GTK+2 support
>> ii  ibus-gtk:i386                                     1.5.1.is.1.4.2-1                   i386         Intelligent Input Bus - GTK+2 support
>
> For you, they were co-installable eventually for you?  I could not do
> this here too initially.  When I tried first, it caused major package
> removal situation.
>

I haven't tried myself, but if they aren't co-installable then it
reveals some packaging mistakes.

> I tried to install all dependency packages of ibus-gtk and faced problem
> with some dependency packages.  If that was caused by packages from
> unstable, I downgraded to testing ones.
>
> Then I was still stack with  libgdk-pixbuf2.0-0 and libgtk2.0-0.
> Tracing this goes to libjasper.  Here libjasper1 (!= 1.900.1-13) but I
> have 1.900.1-14
>
> OK downgrade libjasper1.  Similarly downgrade libcolord1 for ibus-gtk3.
>
> Hmmm... aptitude can select downgrade right but its display does not
> reflect it.  This is confusing but usable...  Now I have
> ibus-gtk/ibus-gtk3 have both i386 and amd64 co-installed.
>
> Anyway, you need to be careful for this kind of downgrade resolution
> problem if you are running mixed system.
>
> libibus-qt1 is not multiarch.  So we can not have ibus-gt* for both
> arch I guess.  So ibus-qt package needs to be updated for multiarch to
> support ibus-qt4 in multiarch setting.
>

Yes.

> For example,
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646973
> libpcre3-dbg: "Multi-Arch: same" but not coinstallable with itself
>
> Not exactly the cause of our bug but this is another indication of how
> imperfect multiarch support is.
>
>> With this, using the 32 bit Mozilla apps seems to work (I can enter
>> Chinese text into a form field). Now only the Emacs question is really
>> open, but emacs is amd64, so the whole multiarch question most likely
>> does not even apply (proceed with fingers crossed - what will happen
>> tomorrow?).
>>
>> > Hmmm... so this is expected problem of current packaging which we have
>> > no easy solution.  This should be true for current testing version too.
>
> I retract this comment.
>
>> Well, I basically have that version that was in experimental for a
>> short time, and that what is now in unstable, although the underlying
>> system is intended to become Wheezy.
>>
>> If things were more predictable, instead of installing one package,
>> then the other to see that the first package was lost, is imho
>> unsatisfactory and misleading, but likely outside the scope of ibus.
>
> Multiarch is major major change.  So expect some rough ride if you wish
> to use that functionality.  It should be smoother for Jessie but wheezy
> is first trial.

Please have a try with Fcitx, as I'm using its Multiarch support in my
everyday life. It works fine since the #1 day of getting Multiarch
support.

--
Regards,
Aron Xu