You build a tool from source on a Linux server and run `make install`. Under the FHS, why does it belong in /usr/local rather than /usr, and when is /opt the right home instead?

## Two guarantees, not two preferences The reason this question is asked is that both answers "work" — a binary in `/usr/bin` runs fine. What differs is the *ownership guarantee*. On a distribution-managed system, every file under `/usr` is claimed by a package. The package database knows which package owns `/usr/bin/curl`, and upgrading that package replaces the file. If you drop your own build of `curl` into `/usr/bin`, one of two things happens: the next upgrade silently overwrites your build, or the package tool refuses to unpack because the path already exists and is not owned by it. Either way you have created a class of failure that appears months later, during an unrelated upgrade, with no obvious connection to what you did. `/usr/local` exists to make that impossible. The FHS states it is for use by the system administrator when installing software locally, and that it must be safe from being overwritten when system software is updated. Distribution policies enforce the other side of the bargain — Debian Policy, for example, forbids packages from installing files into `/usr/local`. So the guarantee is mutual: packages stay out, and your files survive. ## /usr/local mirrors /usr `/usr/local` is not a single flat directory. It carries the same structure one level down: ``` /usr/local/bin /usr/local/sbin /usr/local/lib /usr/local/include /usr/local/share /usr/local/etc /usr/local/src ``` That is why the GNU build system's default `--prefix` is `/usr/local`: a plain `./configure && make && sudo make install` places the binary in `/usr/local/bin`, the man page in `/usr/local/share/man`, headers in `/usr/local/include`. Everything lands in the right shape without any per-project knowledge. Two practical consequences follow. First, `/usr/local/bin` normally precedes `/usr/bin` in the default `PATH`, so a locally installed binary **shadows** the distribution's binary of the same name. That is usually what you want, and occasionally the cause of a mystifying version mismatch — `type -a <name>` shows every match in `PATH` order and settles the argument. Second, shared libraries installed under `/usr/local/lib` are found only if the dynamic linker searches there; distributions handle this with a configuration fragment under `/etc/ld.so.conf.d/` and a run of `ldconfig`, and a missing library at runtime after a source install is very often this and nothing more. ## /opt: self-contained bundles `/opt` answers a different problem. Some software does not want to be spread across `bin`, `lib` and `share` at all; it ships as a tree with its own internal layout, its own bundled runtime, and an expectation that it lives at a fixed path. The FHS gives it `/opt/<package>` or `/opt/<provider>` — a namespace where a vendor may impose its own structure. Typical inhabitants are commercial products, browser and IDE builds, and language toolchains installed outside the distribution. The FHS also carves out `/etc/opt/<package>` for such a package's host-specific configuration and `/var/opt/<package>` for its variable data, keeping the static/local/variable rule intact even for self-contained software. In practice many `/opt` vendors ignore that and keep everything under their own directory; what matters for an interview is that you know the intent. Because nothing in `/opt` is in `PATH` by default, the usual integration is a symlink from `/usr/local/bin` into the bundle, or a small profile fragment that extends `PATH`. ## The neighbouring directory people forget: /srv `/srv` is for data *served by this system* — a web root, an FTP or rsync export, a git repository collection. It is neither the program nor its internal state; it is content this host publishes. Putting a web root in `/srv/www` rather than `/var/www` or `/opt/site` is a defensible choice precisely because `/srv` announces "this is the payload, not the software". ## How to decide - Built from source, follows Unix layout, one tool among many → `/usr/local`. - Vendor bundle with its own tree and fixed install path → `/opt/<vendor>`. - Content this host serves to others → `/srv`. - Anything the distribution's package manager installs → `/usr`, and you never write there by hand. And the mature answer to the whole question: on a fleet, prefer to *package* the software instead. Building a `.deb` or `.rpm` (or shipping it in an image) turns "a directory somebody made on one host" into something with a version, a dependency list and a removal path. `/usr/local` is the right place for a manual install; it is not a substitute for a supply chain.