There are two main ways to organize files from installed software: by package, or by type.
Unix systems tend to organize program files by type: executables in
/usr/bin, executables that are only useful to the system administrator in
/usr/sbin, code libraries and other processor-architecture-dependent files in
/usr/lib, data files that don't depend on the processor type in
/usr/share, manual pages in
/usr/man, miscellaneous documentation
/usr/doc, etc. (This is not an exhaustive list and many variations exist.) I used the prefix
/usr, but there are in fact typically three such fanouts: at
/ for programs that are needed at boot time (this is sometimes merged with
/usr as the distinction is not always relevant), at
/usr for programs that come with the operating system, and at
/usr/local for programs installed manually by the system administrator.
On most Linux systems, the distinction between
/usr/local is that
/) is managed by the package manager, and
/usr/local isn't. So if your application is installed using the by-type structure, it should go under
/usr when distributed as a package (rpm, deb, …) and under
/usr/local when not distributed as a package (e.g. if it's distributed as an archive to be unpacked manually).
Configuration files typically all go in
/etc because they're meant to be modified by the system administrator. If possible, have your application read configuration data from
/etc and either
/usr/local/etc as appropriate, with settings in
/etc/ overriding the ones in
/usr/local/etc. It's common to lump configuration data with other data under
/usr/local/share, so you'll find that many systems don't have
The upside of the by-type organization is that files are placed where they'll be used. All executables are in the directories in the executable search path (
$PATH), all libraries are in the library search path, all manual pages are in the man page search path, etc. The one limitation of this organization is that it requires a package manager to keep track of which files are installed by each package. Since most software on Linux is distributed via a package manager, most software ends up under
Another way to organize files is by package, and the standard place for that is
/opt. It's typically organized as
/opt/APPLICATION/lib, etc., sometimes with an additional level
/opt/AUTHOR/APPLICATION/bin etc. Applications are free to manage their directory however they want, though; some put miscellaneous files directly in
/opt/APPLICATION. This makes package management trivial (just unpack in the right place, use
ls to list installed software, use
rm -r to uninstall) but makes it harder to use the software: the administrator or the user need to add the appropriate locations to search paths, or to use full paths, or to create symbolic links.
/opt are usually managed manually (that's the main point of this organization), but it's possible to have packages there that are managed by a package manager. For example Chrome's deb packages put it under
/opt. An advantage of doing that is that Chrome is always in
/opt/google/chrome regardless of how it was installed; possibly this makes cross-distribution support a little easier.
If you want the details of how applications and distributions should organize files on Linux, read the FHS.
In a nutshell:
- When building a package (deb, rpm, …), install under
/usr, with the distribution's choice of directories (e.g. for
- When installing directly (e.g.
make install), default to installing under
/usr/local (with the default subdirectories: executables in
/usr/local/bin, data files in
/usr/local/share/APPLICATION, etc.), and do support other choices that the system administrator might make. Note that the directory where the files will be copied during installation might not be the same as the directory where the files will be used, for example due to the use of stow (see Keeping track of programs).
/opt is also a possibility in either case, but you're putting more burden on the system administrator.