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

[Takao Fujiwara]

I think It is no problem to add the subdir of the package name in
libexec file paths. However probably I don't think to add the subdir
of arch names for ibus-ui-gtk* at present. I might think
@PACKAGE at -@MAJOR_VERSION@ instead of pkglibexecdir if we would add the
subdir.
It might be an idea to move all arch depended files into /usr/lib*

I think it's often happened to change the file paths using configure
options in many distributions.

fujiwara

On Mon, Feb 6, 2012 at 9:43 PM, Osamu Aoki <osamu at debian.org> wrote:
> 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
>