What is the difference between /opt and /usr/local?

According to the Filesystem Hierarchy Standard, /opt is for "the installation of add-on application software packages". /usr/local is "for use by the system administrator when installing software locally". These use cases seem pretty similar. Software not included with distributions usually is configured by default to install in either /usr/local or /opt with no particular rhyme or reason as to which they chose.

Is there some difference I’m missing, or do both do the same thing, but exist for historical reasons?

Asked By: Patches


They are very similar indeed, and the use of one or the other is more a matter of opinion.
Linux journal had this point/counterpoint discussion about this exact topic here.

Answered By: philfr

For me, personally, it’s what Bill said in @philfr’s link:

On a development system, or a sandbox, having an /opt directory where you can just toss things and see if they work makes a whole lot of sense. I know I’m not going to go through the effort of packaging things myself to try them out. If the app doesn’t work out, you can simply rm the /opt/mytestapp directory and that application is history. Packaging may make sense when you’re running a large deployment (there are times when I do package apps), but lots of times, it’s nice to toss stuff in /opt.

Unfortunately, most make install scripts pushes files into /usr/local instead of just making a symlink there :-/

Answered By: pepoluan

The basic difference is that /usr/local is for software not managed by the system packager, but still following the standard unix deployment rules.

That’s why you have /usr/local/bin, /usr/local/sbin /usr/local/include etc…

/opt on the other hand is for software that doesn’t follow this and is deployed in a monolithic fashion. This usually includes commercial and/or cross-platform software that is packaged in the “Windows” style.

Answered By: Šimon Tóth

While both are designed to contain files not belonging to the operating system, /opt and /usr/local are not intended to contain the same set of files.

/usr/local is a place to install files built by the administrator, typically by using the make command (e.g., ./configure; make; make install). The idea is to avoid clashes with files that are part of the operating system, which would either be overwritten or overwrite the local ones otherwise (e.g., /usr/bin/foo is part of the OS while /usr/local/bin/foo is a local alternative).

All files under /usr are shareable between OS instances, although this is rarely done with Linux. This is a part where the FHS is slightly self-contradictory, as /usr is defined to be read-only, but /usr/local/bin needs to be read-write for local installation of software to succeed. The SVR4 file system standard, which was the FHS’ main source of inspiration, is recommending to avoid /usr/local and use /opt/local instead to overcome this issue.

/usr/local is a legacy from the original BSD. At that time, the source code of /usr/bin OS commands were in /usr/src/bin and /usr/src/usr.bin, while the source of locally developed commands was in /usr/local/src, and their binaries in /usr/local/bin. There was no notion of packaging (outside tarballs).

On the other hand, /opt is a directory for installing unbundled packages (i.e. packages not part of the Operating System distribution, but provided by an independent source), each one in its own subdirectory. They are already built whole packages provided by an independent third party software distributor. Unlike /usr/local stuff, these packages follow the directory conventions (or at least they should). For example, someapp would be installed in /opt/someapp, with one of its command being /opt/someapp/bin/foo, its configuration file would be in /etc/opt/someapp/foo.conf, and its log files in /var/opt/someapp/logs/foo.access.

Answered By: jlliagre

First, I don’t think there is a strict answer; different
adminstrators will have different opinions, according to their
background. Historically, /usr/local came first; it was the
convention in Berkley, IIRC. At one point during the
development of System V, if I’m not mistaken (this is all a long
time ago, and I didn’t take notes), there was a decision or
a desire to be able to mount /usr read-only, which meant you
couldn’t add new software to it; that may have been why /opt
was invented. As it happens, there was just so much existing
software that did write to /usr that that idea never really
got off the ground.

My personal preference is /opt, with a separate subdirectory
for each product; this makes removing a product a simple case of
rm -fr. But if all of your software is installed via a good
package manager, it doesn’t matter, and if the software you
install doesn’t strictly obey these conventions, and writes
configurations and such somewhere under /usr, it doesn’t
matter either, although for the opposite reasons.

Answered By: James Kanze

I have a slightly different take on this issue.
While everything in jlliagre‘s answer is correct, the practical application for me, when deploying software in a cluster, comes down to default environment variables and default reuse of libs.

Simply put – /usr/local and all its child dirs are in the appropriate env vars such as PATH and MANPATH, and /usr/local/lib{,64} are in ldconfig’s (/etc/ld.so.conf.d/).

/opt/ OTOH is not — which is both advantageous when requiring multiple versions or conflicting packages to co-exist in the system, but requires some sort of environment management (e.g., environment-modules or software collections), and disadvantageous in that it would potentially “waste” storage space by duplicating shared libraries, as each installation in /opt can be completely self contained.

For the shared nature of /usr/local to work, it is assumed that e.g. binaries are installed directly to /usr/local/bin (and man pages to appropriate /usr/local/share/man/...) rather than /usr/local/app/{bin,share/man,...} etc.

Answered By: Dani_l

In summary, my gut answer …

Having used my fair share of FreeBSD since 2.2.6 and Red Hat Linux since version 9 …

/usr/local == Old School Conventions
/opt       == New School Conventions

The arrangement of things on UNIX/Linux file systems has more to do with conventions and tradition, than absolute logic.

Otherwise, I mostly agree with everyone else. 🙂

There is always some exception to the rule. At the end of the day, you decide what is best for your set up (when you can).

Answered By: Anthony Rutledge

I have a slightly different take on this old topic.

  • If I am working on a new tool that I intend to be a standard part of the OS.
    • I install it to /usr/local and ask my local users to alpha test it.
  • When I want to beta test it with people outside my company …
    • I put it in /opt because to them it is a 3rd party product.
    • I may still have my cutting edge version in my own /usr/local
    • They probably get a tarball, unless I’ve set up my own package server.
    • but maybe I do publish it with a 0.X.Y SemVer number.
  • When the larger community has finally accepted my tool as the OS component it is meant to be
    • The official package gets re-bundled as part of the OS
    • no longer in /usr/local
    • no longer in /opt
    • no longer a mere tarball

If I want it to be a smooth acceptance, then I follow the FHS and I package it properly from the very beginning.

If I was a cowboy to start with, and didn’t follow FHS, or just made tarballs and never packaged it, then there is re-factoring work required before it can be accepted.

Some packages/tarballs never get out of /opt, some never get out of /usr/local

But in my opinion, this flow is likely what was intended back then when it was chosen.

Answered By: Jesse Chisholm

To add onto the existing answers, I’ve decided by convention that /usr/local is where to install projects that use a traditional make approach, so binaries go in /usr/local/bin, libraries go in /usr/local/lib, etc. The makefile should automatically put them there, but sometimes I need to copy standalone binaries to /usr/local/bin. /opt is for projects that don’t follow the traditional make procedure like java projects or applications without source, however since I’m the only user it is fine to leave in my home directory.

One question remains: where should the source code be kept (if it is)? Standard location for holding software source files suggests optionally putting in /usr/local/src for reference or just leaving around the home directory.

Answered By: qwr
Categories: Answers Tags: ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.