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

[Daiki Ueno]

Ma Xiaojun <damage3025 at gmail.com> writes:

> Though IBus seems to assume quite much about paths, this actually
> violates the philosophy of Autotools and/or GNU Coding Standard IIRC.

Which part of the standards are you referring to?  I don't think they
define any policy nor philosophy on such a path usage.  In Debian, the
only mention of libexec I found is in the New Maintainers' Guide:

http://www.debian.org/doc/manuals/maint-guide/advanced.en.html#ftn.idp2063600

"Please note that --libexecdir specifies the default path to install
executable programs run by other programs rather than by users. Its
Autotools default is /usr/libexec/ but its Debian default is /usr/lib/."

This is presumably for the conformance with FHS.

And appending source package name to libexecdir seems to be an
undocumented convention which was implemented by earlier Debhelper:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541458

"/usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm sets
libexecdir to $prefix/lib/$sourcepackage. This is unhelpful - Autoconf's
default for libexecdir is $prefix/libexec (which should obviously be
$prefix/lib instead on Debian), and in Automake you're supposed to use
pkglibexecdir if you want a package-specific subdirectory."

So, I think it is legitimate that IBus (or ibus Debian package) assumes
ibus-setup-* executables stored in a single directory.  Moreover,
perhaps it might be rather natual to install ibus-engine-* and
ibus-setup-* executables in /usr/lib/<arch>/ibus, because they are
called by ibus-daemon or ibus-setup in most cases.  It might be compared
to other plugin packages like gtk theme engines.

Regards,
-- 
Daiki Ueno