Directories 2

In a Linux filesystem hierarchy, both /opt/ and /usr/local/ are valid places to install software that doesn’t come from the system’s base distribution (e.g., apt, yum). They serve slightly different purposes and follow different conventions:

 

1. /opt/ (Optional Software)

• Purpose: Reserved for “optional” software that is usually third-party, proprietary, or self-contained. Often these are large bundles or standalone packages that don’t necessarily follow the usual Unix directory structure.

• Self-Contained: Software placed in /opt/ typically has all its files (binaries, libraries, data) under one top-level directory, like /opt/myapp/.

• Examples: Commercial applications, proprietary enterprise apps, or large self-contained packages like MATLAB, VMware tools, or certain packaged HPC software distributions.

• Installation Pattern: You might see something like /opt/<package_name>/<version> to keep multiple versions of the same application separate.

 

2. /usr/local/ (Locally Installed Software)

• Purpose: Intended for “local” installations—software that you (the system admin or user) compile or install from source, or from external sources, that you want to keep separate from distribution-managed packages in /usr/.

• Follows Standard Directory Layout: Within /usr/local/, you often see bin/, lib/, include/, etc. This mirrors the /usr/ hierarchy, but is “local” and usually not touched by the system package manager.

• Examples: Small utilities you’ve compiled yourself (make install goes into /usr/local/bin by default), local libraries (/usr/local/lib), or scripts for local system administration.

 

3. Which Should You Use?

• Self-Contained, 3rd-Party, or Vendor-Supplied Package?

• If you want to keep a vendor-supplied or commercial package entirely separate from system paths, /opt/ is preferred.

• It’s also common for very large, monolithic software that bundles all of its dependencies.

• Locally Compiled or Custom Builds for Your System?

• If you’re building open-source software from source, or want to keep custom versions in a place recognized by your system as “local,” /usr/local/ is generally the standard approach.

• This allows you to still use typical Unix conventions (/usr/local/bin in $PATH, /usr/local/lib for libraries, etc.).

 

In Practice

• Multi-user HPC System: Sysadmins might install “optional” HPC modules in /opt to keep them self-contained, then use environment modules to toggle them on/off for different users.

• Personal or Developer Workstation: Users often compile and install to /usr/local/ by default, ensuring it doesn’t conflict with distro-supplied binaries in /usr/bin.

 

Ultimately, the choice often boils down to organizational preference, size or packaging style of the software, and whether you want to keep it strictly separate (/opt) or integrated into your local Unix filesystem layout (/usr/local).