[Pkg-ime-devel] Bug#657828: Re: [ibus-devel] Prepare ibus 1.4.1

[Osamu Aoki]

Hi thanks for your insights,

> On Sun, Feb 5, 2012 at 10:41 PM, Peng Huang <shawn.p.huang at gmail.com> wrote:
> > I guess fedora does not have hard rule for internal exe files. The
> > application can install them in libexec or pkglibexec. But seems most apps
> > will install them in libexec. So I am think debian have to patch many apps
> > for installing internal exec in pkglibexec, right?

For me, patching on Debian side is OK.

FYI: In the mean time, I found an interesting document for FEDORA and
Debian related to this issue.

http://fedoraproject.org/wiki/Packaging:Guidelines#Libexecdir

| Libexecdir
| The Filesystem Hierarchy Standard does not include any provision for
| libexecdir, but Fedora packages may store appropriate files there.
| Libexecdir (aka, /usr/libexec on Fedora systems) should only be used as
| the directory for executable programs that are designed primarily to be
| run by other programs rather than by users.

This part, I knew.

| Fedora's rpm includes a macro for libexecdir, %{_libexecdir}. Packagers
| are highly encouraged to store libexecdir files in a package-specific
| subdirectory of %{_libexecdir}, such as %{_libexecdir}/%{name}.

So Packaging:Guideline recommends to use /usr/libexec/ibus to store
internal binaries. (I do not know if this Packaging:Guideline is
consensus of FEDORA people) But use of /usr/libexec is fine.

As Peng stated, I see all these files directly under %{_libexecdir}
in ibus.spec:
|...
| %{_libexecdir}/ibus-gconf
| %if %{build_python_library}
|     %{_libexecdir}/ibus-ui-gtk
| %endif
| %{_libexecdir}/ibus-ui-gtk3
| %{_libexecdir}/ibus-x11
| %{_libexecdir}/ibus-engine-simple

| If upstream's build scripts support the use of %{_libexecdir} then that
| is the most appropriate place to configure it (eg. passing
| --libexecdir=%{libexecdir}/%{name} to autotools configure). If
| upstream's build scripts do not support that, %{_libdir}/%{name} is a
| valid second choice. If you have to patch support for using one of these
| directories in, then you should patch in LIBEXECDIR, preferably
| configurable at build time (so distributions that do not have
| /usr/libexec can set LIBEXECDIR to another directory more appropriate
| for their distro.

If you change mind to install these under %{_libexecdir}/%{name}
following Packaging:Guideline, use of the new automake feature of
pkglibexec for Makefile.am like my patch makes thing simpler for you.
You do not need to pass --libexecdir=%{libexecdir}/%{name} to autotools
configure but and can just run ./configure without argument.

I also took deep look at Debian policy, it seems there is no policy
requiring it.  Debian follows FHS-2.3+multiarch:

| /usr/lib : Libraries for programming and packages
| 
| Purpose
| 
| /usr/lib includes object files, libraries, and internal binaries that
| are not intended to be executed directly by users or shell scripts. [22]
| 
| Applications may use a single subdirectory under /usr/lib. If an
| application uses a subdirectory, all architecture-dependent data
| exclusively used by the application must be placed within that
| subdirectory. [23]

Use of pkglibexec is just "may" requirement.  Use of /usr/lib seems OK
for internal binaries, too.   Interesting ...  So it is just a cosmetic
consistency issue.  

On Mon, Feb 06, 2012 at 12:35:47AM +0900, Takao Fujiwara wrote:
> If your platform has the different libexec path, you could use
> configure --libexecdir .

I did not want to use special case build script but this is very true. 
Compared to patching Makefile.am, this is much simpler.
====
 configure --libexecdir /usr/lib/x86_64-linux-gnu/ibus
====
for Debian.  This is certainly cleaner solution although it requires a
bit complicated overrides configuration in its actual Debian package
script implementation since we need to support so many architectures
such as HURD/KFreeBSD/ARMHF/....  I will use this approach for upcoming
1.4.1 unless you start using %{_libexecdir}/%{name} with pkglibexec :-)

I CCed Debian bug report for remembering this.

Thanks,

Osamu