[FHS] helper scripts location

80 karlthered at gmail.com
Tue Jun 14 09:57:03 UTC 2011


2011/6/14 Ralf Corsepius <rc040203 at freenet.de>:
> On 06/14/2011 12:26 AM, Kevin Kofler wrote:
>> Haïkel Guémar wrote:
>>> I spent some time yesterday talking with opensuse guys on irc, since
>>> /usr/libexec has not been blessed by FHS
> libexecdir is GNU Standards for ages (decades).
>
> It's supposed to be kind of an "auxilliary bindir", to hide away
> programs, users are not supposed to execute directly.
>
> It's formal definition[1] is
>
> <cite>
> libexecdir
>
>     The directory for installing executable programs to be run by other
> programs rather than by users. This directory should normally be
> ‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you
> are using Autoconf, write it as ‘@libexecdir@’.)
>
>     The definition of ‘libexecdir’ is the same for all packages, so you
> should install your data in a subdirectory thereof. Most packages
> install their data under ‘$(libexecdir)/package-name/’, possibly within
> additional subdirectories thereof, such as
> ‘$(libexecdir)/package-name/machine/version’.
> </cite>
>
> In Fedora, we treat libexecdir as optional and allow packages to install
> such "non-user programs" to %libdir/<subdir>/ instead, primarily for
> historical reasons.
>
>> Actually, libexec can be interpreted as being a libdir with the multilib
>> suffix "exec" (just like "64" is one),
> Multilib subdirs are arbitrary directory names. There is no convention
> of them being named "lib*".
>
> You might not have tripped over such them on intel based platforms, but
> are very common on other architectures/OSes.
>
> Ralf
>
> [1] http://www.gnu.org/prep/standards/standards.html
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Do we agree that until FHS canonicalize libexecdir, libexecdir is the
recommended location for helper scripts and that /usr/{lib,share} are
*tolerated* (ie: not configurable, requires non-upstream-able
intrusive patch etc ...) ? In consequence, we should then update
packaging guidelines to explicitely state this.

http://bugs.linuxfoundation.org/show_bug.cgi?id=101


More information about the devel mailing list