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@-@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 <os...@debian.org> wrote: > 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-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
