[Pkg-ime-devel] [ibus] about ibus input engine packaging.

[Osamu Aoki]

Hi,

Now that I tested, pinyin does not show up in ibus menu.  So there may
be some real bug (not just aesthetic inconsistency).  Wait, after
rebooting my wheezy X system, it showed up.

Right-top-inputmethod-icon -> right click -> Preference -> click tab for
Input Method, select an input method, chinese, pinyin menu.... but anthy
can be activated but pinyin can not it with Right-top-inputmethod-icon
-> left click to open -> left click on pinyin.

I can not activate pinyin while anthy can.

Are you talking about this as bug?

Wait, by rebooting my wheezy X system, these can be activated.  

OK, so problem is not about pinyin itself is usable but its lack of hot
update of ibus configuration.

I do not know if this is due to packaging error or upstream design
feature shortcomings.

Here is my note following the discussion as below are motly before
finding the above key facts.

On Sat, Jun 08, 2013 at 01:28:09PM +0800, Ma Xiaojun wrote:
> On Sat, Jun 8, 2013 at 12:54 PM, Osamu Aoki <osamu at debian.org> wrote:
> > As for ibus source package in wheezy, it is half-way to complete
> > multi-arch conversion.  How we split its binaries into multiple packages
> > may need to be reconsidered for jessie.  We now have:
> >
> > Package: ibus
> > Architecture: any
> > Multi-Arch: foreign
> >
> > Thus, this package made of the compiled program files, not
> > co-installable.
> >
> > As I see:
> > $ dpkg -L ibus
> > ...
> > /usr/lib/x86_64-linux-gnu/ibus/ibus-x11
> > /usr/lib/x86_64-linux-gnu/ibus/ibus-gconf
> > /usr/lib/x86_64-linux-gnu/ibus/ibus-ui-gtk
> > ...
> >
> > These look a bit odd since these files are not meant to be co-installed.
> > This is deaper issue than the original poster mentioned.
> >
> > (The rationale behind moving to the multi-arch for the ibus family was
> > to support input to wine running under i386 for amd64 etc.)
> 
> Yes. IM Module stuff need multi-arch. As one may download Firefox from
> Mozilla which is still 32bit? I'm not sure about XIM.

I know there is no quick answer but let's put aside how best we can do
for jessie but fix wheezy package bug affecting user.

> > Yes. (The real question is do we need to use Multi-Arch enabled path for
> > Multi-Arch: foreign package as it is packaged.)
> >
> > In short, Debian decided to use /usr/lib for /usr/libexec as policy.
> > Upstream is FEDORA oriented.  Here, preference is working for me.
> > (You can google for debian-devel ML for how it was debated.)
> >
> > Basically, files under /usr/libexec are for plug-in binary executables
> > not meant to be called directly from shell prompt.  Usually, the package
> > specific subdirectly is created.  But ibus ustream did not.

Since they are package specific, as long as path matches, it is OK where
ever they are.

> > Since /usr/lib (or /usr/lib/x86_64-linux-gnu) is much more cluttered, we
> > decided to use /usr/lib/ibus (or /usr/lib/x86_64-linux-gnu/ibus).
> >
> > Can you be specific which packages you have issues?  I may have missed
> > discussion or bug #.
> >
> > Hmmmm... I am lost here.  I do not have ibus-*-setup here.  Where are
> > they?  Anyway, if we have problem in Debian, let's fix it here first.
> > If we are sure about it affects upstream, let's propose something to
> > upstream.  The choice of directly is not something we dictate when they
> > are following FEDORA practice.
> >
> > $ which ibus-setup
> > /usr/bin/ibus-setup
> > $ dpkg -S bin/ibus-setup
> > ibus: /usr/bin/ibus-setup

I poked this file and found out this is nothing but a shell
/usr/share/ibus/setup/main.py wrapper.

----
prefix=/usr
exec_prefix=${prefix}
datarootdir=${prefix}/share
libexecdir=/usr/lib/x86_64-linux-gnu/ibus
export IBUS_PREFIX=/usr
export IBUS_DATAROOTDIR=${prefix}/share
export IBUS_LOCALEDIR=${datarootdir}/locale
export IBUS_LIBEXECDIR=${libexecdir}
exec /usr/bin/python /usr/share/ibus/setup/main.py $@
----

> I got it wrong. It should be ibus-setup-*, e.g., ibus-setup-anthy.
> http://packages.debian.org/sid/amd64/ibus-anthy/filelist

I see these packages have both ibus-engine-* and ibus-setup-*:
  /usr/lib/ibus-anthy/ibus-engine-anthy
  /usr/lib/ibus-anthy/ibus-setup-anthy 
  /usr/lib/ibus-pinyin/ibus-engine-pinyin
  /usr/lib/ibus-pinyin/ibus-setup-pinyin

But my usual one does not come with ibus-setup-*.
  /usr/lib/ibus-mozc/ibus-engine-mozc

> The default path ibus-setup looks for is $libexecdir/ibus-setup-$engine_name .

None exit there.

The minimal patch fix seems to create symlink in the
/usr/lib/x86_64-linux-gnu/ibus pointing to all these files
by ibus-anthy and ibus-pinyin.  Since Multi-Arch: foreign for ibus and
non-multiarch for ibus-anthy or ibus-pinyin, this is decent compromize
for wheezy.  The best is change everything to use
/usr/lib/ibus.  But that is for jessie.  For now, I think minimal patch
strategy to get it accepted by stable release managers.

But I need to know a bit more to be sure what I am doing :-)

> If there is a <setup> in $engine_name.xml, .e.g, anthy.xml , then
> ibus-setup would use that.

Hmmm... you mean files in /usr/share/ibus/component with exec specified
as:
  anthy.xml <exec>/usr/lib/ibus-anthy/ibus-engine-anthy --ibus</exec>
  gconf.xml <exec>/usr/lib/x86_64-linux-gnu/ibus/ibus-gconf</exec>
  gtkpanel.xml <exec>/usr/lib/x86_64-linux-gnu/ibus/ibus-ui-gtk</exec>
  mozc.xml <exec>/usr/lib/ibus-mozc/ibus-engine-mozc --ibus</exec>
  pinyin.xml <exec>/usr/lib/ibus-pinyin/ibus-engine-pinyin --ibus</exec>

So all of them are alling ibus-engine-* directly without ibus-setup-*.

They all pointing to the file location.  As long as files are there, it does
not break thing although this confusion is mess.

> Some engines have <setup> tag for whatever reasons. But IBus upstream

Please be specific.  Which engine does and does not.  We are not
following you.

> refused to add <setup> to all engines unless it is really needed.

I am not quite sure what you mean by "<setup> tag".

The /usr/lib/ibus-anthy/ibus-setup-anthy is a simple shell wrapper to
run /usr/share/ibus-anthy/setup/main.py . 
-----
prefix=/usr
datarootdir=${prefix}/share
export IBUS_LOCALEDIR=${datarootdir}/locale
exec /usr/bin/python /usr/share/ibus-anthy/setup/main.py $@
-----

Very similar for ibus-setup-pinyin as it is:
----
prefix=/usr
exec_prefix=${prefix}
datarootdir=${prefix}/share
export IBUS_PREFIX=/usr
export IBUS_DATAROOTDIR=${prefix}/share
export IBUS_LOCALEDIR=${datarootdir}/locale
cd /usr/share/ibus-pinyin/setup/
exec python main.py $@
----

Are these script called by any script? Who use them?

> ibus-pinyin and ibus-libpinyin have <setup> tag because they actually
> expose two engines to users. But I'm not sure whether ibus-pinyin in
> Debian has <setup> tag as it is not latest and latest requires IBus
> 1.5.x

We know the real 1.5 series needs to be packaged once GNOME is updated.

Right now it is a bit confusing versioning but we have 1.4.2 packaged as
1.5.1.is.1.4.2-1.

Anyway, if you know how exactly these 

 ibus-setup-*
 ibus-engine-*
 *.xml

interact, it may be helpful for all of us.

*.xml for pinyin is odd ball since it has 2 engines and thus has
<engines> tag inside *.xml.

I think there is some bug in pinyin family of ibus packages in terms of
hot update without restarting process now.  This part of discussion is
for jessie cycle.

Osamu