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

[Ma Xiaojun]

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.

> 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 /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 got it wrong. It should be ibus-setup-*, e.g., ibus-setup-anthy.
http://packages.debian.org/sid/amd64/ibus-anthy/filelist

The default path ibus-setup looks for is $libexecdir/ibus-setup-$engine_name .
If there is a <setup> in $engine_name.xml, .e.g, anthy.xml , then
ibus-setup would use that.

Some engines have <setup> tag for whatever reasons. But IBus upstream
refused to add <setup> to all engines unless it is really needed.
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