[Pkg-ime-devel] [ibus] about ibus input engine packaging.
osamu at debian.org
Thu Jun 13 11:43:24 UTC 2013
Thanks for very through technical review.
On Tue, Jun 11, 2013 at 12:58:14PM +0900, Daiki Ueno wrote:
> 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:
(This section was written by me. There were many long debian-devel
discussions by prominent developers. I summarized the consensus.)
> "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:
Well that was where I got this idea.
I did not know this change .... I see.
(The fact that joeyh changed his previous decision on Debuhelper
defaults is very interesting. This means at least there were some
consensus to do like v8. I was siding with this v8 thinking. rleigh
was right, I guess.)
> "/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
Well I see "if (! compat(8))...".
Now that I re-read debhelper(8) manpage, the current recommended
debhelper v9 mode lists:
- Multiarch support. In particular, dh_auto_configure passes
multiarch directories to autoconf in --libdir and
- dh_auto_configure does not include the source package name
in --libexecdir when using autoconf.
> in Automake you're supposed to use
> pkglibexecdir if you want a package-specific subdirectory."
Well, that is for upstream. Patching automake script is certainly one
option but simply using override_dh_auto_configure in debian/rules
should be another option. I think override makes it more clear to
others that this is done by Debian for Debian only. (Not a bug fix.)
> So, I think it is legitimate that IBus (or ibus Debian package) assumes
> ibus-setup-* executables stored in a single directory.
Legitimate, I do not know :-)
By making all of ibus packages to use debhelper v9, it should work this
> perhaps it might be rather natural 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.
Natural, I do not know :-)
But aesthetically, I am tempted to agree not to contaminate the
/usr/lib/ directory if it is not too complicated. This should be agreed
among Debian ibus packagers. This is nothing to do with upstream nor
debhelper. This is purely a customization by Debian packagers. This
means to place all ibus plug-in executables to be located in
/usr/lib/ibus/. (If these ibus plug-in executables are "multi-arch:
same", /usr/lib/<arch>/ibus/ instead, of course. But it seems all these
ibus plug-in executables are "multi-arch foreign.)
For released wheezy, the most simple fix is required and that should be
the first option with v9. We can decide for Jessie, later.
But before going further, let me check some sources....
ibus but override has --libexec=/usr/lib/$(DEB_BUILD_MULTIARCH)/ibus
Looks like removing override for --libexec for ibus and set compat=9 for
others seems to be the simplest solution for wheezy.
For Jessie, we can set override --libexec=/usr/lib/ibus for all
packages, if we agree.
More information about the Pkg-ime-devel