I have been using Linux servers for years now and I keep on being confused by the Filesystem Hierarchy Standard. Usually, I can live with the confusion. But now that I am developing my own software for Linux, I need to understand where it is supposed to be installed by package managers.

I was pretty convinced that /opt was the perfect location for my application. But after having investigate my Debian filesystem, I'm not sure anymore : a lot of softwares are actually installed in /usr/lib ! To name a few : MySQL, MySQLWorkbench, Nautilus, Rythmbox...

According to the FHS, /usr/lib is supposed to contain "Libraries for programming and packages" and "includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts" (See here).

A lot of softwares located in /usr/lib of my debian server are not libraries or internal binaries but full-fledged user executable softwares !

I'm still on track to have my application installed in /opt. But I really would like to understand if this is correct and, above all, why.

Thanks by advance for your kind advices,


  • 2
    Spot checking, from what I can tell MySQLWorkbench installs only libraries under /usr/lib. What makes you think that there is "full-fledged user executable software" in /usr/lib? Aug 27 '13 at 19:40
  • The actual shortcut located in the Application menu point to a binary located in /usr/lib, if I remember correctly. Aug 28 '13 at 9:36
  • You seem confused about where the software you listed is installed. Here are links to listings if the files for MySQL and Nautilus. Notice that the files are split among /etc, /usr/bin, /usr/lib etc. just like FHS says they should be. packages.debian.org/wheezy/i386/mysql-server-5.5/filelist packages.debian.org/wheezy/i386/nautilus/filelist
    – sciurus
    Sep 1 '13 at 1:15

The real key to understanding the Filesystem Heirarchy Standard is knowing that it is designed with network filesystems in mind.

For every machine of the same OS, release, and architecture, you can share /usr via NFS and mount it.
/usr is (re)mounted after the network stack is initialized.

/var <-- local, r/w optimized
/usr <-- can be mounted over network, possibly even read-only!
/opt <-- local, read mostly
/etc <-- local, read mostly
/srv <-- local, r/w optimized

/home <-- either/or
  • Would you mind providing a link for the local/remote and r - r/w standards? Aug 27 '13 at 20:27
  • Does this mean that one can have a single /usr "repository" for every Linux server or workstation in a network ? Aug 28 '13 at 9:39
  • 1
    It takes some work, but yes, you can. Back when hard drives where expensive this was the norm for any large rollout. Aug 29 '13 at 13:26
  • @eric-morand From the FHS: "/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY Aug 29 '13 at 13:32
  • Whoops. The above comment was for @CaptainGiraffe Aug 29 '13 at 14:04

The difference is that /usr is meant to hold packages installed as part of the system. Packages you get from the Debian/Ubuntu repositories, PPAs, etc., go here. While /opt is meant for unbundled third party applications that are not distributed through the distribution's package distribution process.

If you distribute .deb or .rpm packages, with an eye toward eventually getting your software included in the official repositories, you should install to /usr. Otherwise install to /opt. In either case, your application should be able to be compiled to run in any arbitrary location (e.g. with the help of the GNU autotools).

  • Thanks. Right now, I have no plan to have my app included in the official repository. Aug 28 '13 at 9:38
  • What about /usr/local, then? Or is that discrete Sep 2 '13 at 15:03
  • @AaronCopley /usr/local wasn't in scope for this question. But it's meant for third-party software that the local administrator compiles and installs. Sep 2 '13 at 15:04
  • That is why I asked if it would be considered discrete. Sep 2 '13 at 15:48

You install your libraries in <prefix>/lib , your binaries in <prefix>/bin, your header files in <prefix>/include, man pages in prefix/[share/]man, pkgconfig files in <prefix>/lib/pkgconfig or <prefix/share/pkgconfig, your cmake .m4 files in <prefix>/share/aclocal

Then let package manager decide on the prefix. If you are distributing rpm's/deb's yourself, /usr is a good choice for a prefix.

./configure --prefix=~/.local/ Should still work, so don't go hardcoding your path anywhere please!

Some libraries are wrapped into some other tool that makes them also executable and usable as a library, but they are still libraries, and not in your $PATH, so it is ok to puth them in /lib I guess.


I would suggest to avoid installing your app under /opt. Reason 1 : Some distros do not have /opt by default Reason 2 : /usr/lib is a standard path for libraries {If other applications need to use your library you need to add your library path manually to /etc/ldconfig} /opt is more convenient when you have standalone apps which you install manually and you want to know where they are located

One of the reason that fully fledged executables are located under /usr/lib could be that they are used from other scripts. {For example bash scripts cannot use an API directly. for this reason a common trick is to build a "wrapper" around this api and push parameters as script's arguments }

  • 2
    I disagree. If he wants to install in /opt, the package manager will create the directory, so that is a non issue. Also, binaries installed in /usr/lib is a bad idea.
    – Walter
    Aug 28 '13 at 1:14
  • Thanks @Nikolaidis Fotis. But in my case, my app does not contain a public library and will not be used by other applications. Aug 28 '13 at 9:40

Please, install it in /opt.

Way too many Linux applications make the same make that Windows developers made in the 90's.

Lets install our stuff in C:\windows so that it is simple and easy to find (and slightly faster). Then came 15 years of DLL hell as different software packages needed different versions of the same libraries (which in Windows didn't have versioning of the the libraries).

Unless you are writing actual system software, put it in /opt, so that people can better track who installed what.

  • 4
    This isn't Windows. We have package managers that work and this really isn't much of an issue. Aug 28 '13 at 1:27
  • If you're really that worried about everything being in the same tree, check out the Nix package manager. Best of both worlds, if you ask me.
    – TheSola10
    Mar 4 '19 at 11:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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