Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am making quite some binaries, scripts etc that I want to install easily (using my own rpms). Since I want them accessible for everyone, my intuition would be to put them in /usr/bin;

  • no need to change PATH

however; my executables now disappear in a pool of all the others; how can I find back all the executables I put there in an easy way. I was thinking of:

  • a subdirectory in /usr/bin (I know I cannot do this; just to illustrate my thinking)
  • another directory (/opt/myself/bin) and linking each executable to /usr/bin (lots of work)
  • another directory (/opt/myself/bin) and linking the directory to /usr/bin (is this possible?)

what would be the "best, most linux-compliant way" to do this?

EDIT: we had a discussion on this in the company and came up with this sub-optimal option: put binaries in /usr/bin/company with a symbolic link from /usr/bin. I'm not thrilled with this solution (disussion ongoing)

share|improve this question
up vote 7 down vote accepted

If you bundle your binaries into your own RPMs then it's trivial to get a list of what they are and where they were installed.


$ rpm -ql httpd| head -10

I would suggest putting your executables in either /usr/bin or /usr/local/bin and rolling your own RPM. It's pretty trivial to do this and by managing your software deployment using an RPM you'll be able to label a bundle with a version number further easing the configuration management of your software as you deploy it.

Determining which RPMs are "mine"?

You can build your RPMs using some known information that could then be agreed upon prior to doing the building. I often build packages on systems that are owned by my domain so it's trivial to find RPMs by simply searching through all the RPMs that were built on host X.mydom.com.


$ rpm -qi httpd
Name        : httpd
Version     : 2.4.7
Release     : 1.fc19
Architecture: x86_64
Install Date: Mon 17 Feb 2014 01:53:15 AM EST
Group       : System Environment/Daemons
Size        : 3865725
License     : ASL 2.0
Signature   : RSA/SHA256, Mon 27 Jan 2014 11:00:08 AM EST, Key ID 07477e65fb4b18e6
Source RPM  : httpd-2.4.7-1.fc19.src.rpm
Build Date  : Mon 27 Jan 2014 08:39:13 AM EST
Build Host  : buildvm-20.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://httpd.apache.org/
Summary     : Apache HTTP Server
Description :
The Apache HTTP Server is a powerful, efficient, and extensible
web server.

This would be the Build Host line within the RPMs.

The use of /usr/bin/company?

I would probably discourage the use of a location such as this. Mainly because it requires all your systems to have their $PATH augmented to include it and is non-standard. Customizing things has always been a "right of passage" for every wannabee Unix admin, but I always discourage it unless absolutely necessary.

The biggest issue with customization's like this is that they become a burden in both maintaining your environment and in bringing new people up to speed on how to use your environment.

Can I just get a list of files from RPM?

Yes you can achieve this but it will require 2 calls to RPM. The first will build a list of packages that were built on host X.mydom.com. After getting this list you'll need to re-call RPM querying for the files owned by each of these packages. You can achieve this using this one liner:

$ rpm -ql $(rpm -qa --queryformat "%-30{NAME}%{BUILDHOST}\n" | \
    grep X.mydom.com | awk '{print $1}') | head -10
share|improve this answer
and how to get a list of all binaries that were installed by all rpms I installed? Luckily we agreed to put our company name in the rpm names; so something like "rpm -qa | grep company" lists my rpms installed – Chris Maes Apr 2 '14 at 16:28
@ChrisMaes - see updates. I use build host to determine which pkgs are "mine". – slm Apr 2 '14 at 18:37
thanks for the update; if you could just add a command to find all binaries owned by my rpms (which have "company" in their name) that would be fantastic – Chris Maes Apr 2 '14 at 18:52
@ChrisMaes - see update, LMK if you need further guidance. – slm Apr 2 '14 at 20:21
very nice written answer; complete and well formatted. Thanks a lot! – Chris Maes Apr 2 '14 at 20:35

An obvious suggestions is to name your binaries or your packages in a special way. So for example you could prefix them with cm-, per your initials as given in this post. If you are installing rpms they need to go into /usr/bin (if they are user level executables), per the FHS. They should not go into /usr/local/bin for example. That is for local installs only.

For the record, I don't find the idea of putting binaries in a special directory and linking them appealing at all, though I suppose such things are sometimes done. Bear in mind also that if you need to find out which binaries belong to which package, you can just query the packaging system.

share|improve this answer

Binaries not part of the system or distribution are usually in


the directory is usually in the standard $PATH so that your binaries will be found.

share|improve this answer
normally /usr/local/bin is for binaries that exist only "locally" on that machine; not for binaries I will distribute on other machines using an rpm...? – Chris Maes Apr 2 '14 at 15:15
Under Linux, /usr/local/bin is for manually installed executables. Executables managed by the package manager go into /usr/bin. – Gilles Apr 2 '14 at 21:28
@Gilles, my first interpretation of the question was to install on a single machine making the binaries available to every user (not installing in $HOME). Now I see that it was not really what I understood. – Matteo Apr 3 '14 at 6:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.