Hi thanks for your insights, > On Sun, Feb 5, 2012 at 10:41 PM, Peng Huang <shawn.p.hu...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
