I'm in the process of creating a package for a bioinformatics toolkit that builds several dozen binaries and scripts. As it stands, these all get installed into the 'bin' directory under whatever prefix the package manager uses. I ran this by the folks who maintain the package repository and this made them frown, since it creates many opportunities for file name collisions with other packages.

Most users will only use about 9 of the executables. The remainder are utility programs, such as file format converters. The package repository managers suggested installing the other executables in a subdirectory under libexec. That would be easy enough to do, but I'm a little concerned that it doesn't conform to the stated purpose of libexec in the Filesystem Hierarchy Standard, since the executables are intended to be run by end users directly.

Is there a better destination for a package to install several dozen, infrequently used executables?

  • The ideal place would be /opt, but that will open the door to complaints from various quarters. Oct 27, 2017 at 1:17
  • Can you not pre-build the binaries and provide a distro-appropriate package of the whole thing?
    – ivanivan
    Oct 27, 2017 at 1:22
  • @MatthewGauthier: /opt is never a good place on most Linux distributions. It was a Solaris and SunOS thing, and it is a very bad idea, because it often requires the user to have a very long $PATH Oct 27, 2017 at 6:35

3 Answers 3


libexec is fine, the postfix MTA for example on RedHat has a bunch of tools under /usr/libexec/postfix. For another option mailman as packaged on RedHat uses /usr/lib/mailman/bin for its command line utilities (newlist, list_lists, etc).

however if the utilities need to be in PATH then you'll also need to be sure to adjust the shell configs to include that (or instead just dump everything in a bin directory and be done with it, or for the utilities not in PATH to fully qualify the PATH to them in things that do need to call them...)


On a libexec-using system, /usr/libexec/yourpackage is fine, as explained by thrig. /usr/lib/yourpackage works anywhere.

That doesn’t solve the issue of access. Adding the new directory to the path might not be appropriate since that re-introduces the collision problem. A potential solution is to use a launcher script in /usr/bin, in the same style as git with all its subcommands; let’s call it bit (bio-informatics toolkit):



if [ ! -x "${prefix}/$1" ]; then
    echo Unknown bit subcommand "$1"
    exit 1

exec "${prefix}/$1" "$@"

Once your users have retrained their fingers, your package’s tools will be reasonably accessible...

  • I would set prefix=/usr/libexec/yourpackage/ without any bin Oct 27, 2017 at 6:21

Be aware that /usr/libexec/ (or some sub-directory in it, or elsewhere e.g. under /usr/lib) is not meant (and should not be) in the user's $PATH, which could be as short as /bin:/usr/bin. Executables there should never be directly started by the user, only by some specific other (user-started) program (which is not a shell). For example, g++ is starting /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus (and the user is not expected to run that cc1plus program directly).

It is ok to have a package installing several executables in /usr/bin/ (which is in $PATH), and that directory is expected to be quite big. I have more than 4400 files there, and the single coreutils package install over 100 executables in it.

You could decide that your package's user always use a single driving program, a bit like git.

You might share a common prefix for your package's executables. For example all XFCE related binaries start with xfce, and all LXDE binaries start with lx. Actually, I would recommend following a similar convention.

Or you could split your package in several ones, if it makes sense to not even install some executables.

You might even design your packaging to allow several versions of your suite to co-exist (e.g. I have gcc-6 and gcc-7).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .