Should I put application into /usr/local or /usr/local/share?
What are the «standards» — should I put application (not just binary, but entire distribution) to /usr/local or /usr/local/share. For example scala or weka — it contains examples, binaries, libraries, and so on. So it would be
Since I am the only admin it is not a big deal for me, but I prefer to using something which is widely used, not with my own customs. Important: I am not asking about cases, where you should split app into /usr/local/bin, /usr/local/lib and so on. Rather I am asking about case when you have to keep one main directory for entire application.
@Faheem Mitha, very good point. Thanks to you I found such explanation «/opt/’provider’ directory tree, similar to the way in which Windows will install new software to its own directory tree C:\Windows\Progam Files\»Program Name» from linuxtopia.org/online_books/linux_beginner_books/… Could you please post your comment as answer, so I would mark it as THE answer? Thank you.
@greenoldman: also please realize that keeping all files in a single dir is not the «standard» way to install applications in Unix. /opt is indeed the right answer, but it is not «widely used» by traditional Unix/Linux software. There are great reasons to split your files in multiple dirs, and also to differenciate /usr from /usr/local
For example, keeping all executables from all applications in a single /usr/bin (or /usr/local/bin ) allows your $PATH to reach all software without needing to edit it for each software, a concept that does not exist in Windows
Neither. The *nix standard for this is bad. Put your program in the root of a single, easily deletable directory that exclusively contains your program’s files. If you make a cache, put it in a subfolder of the program’s dir named «cache». If you save any user configuration or persistent state whatsoever, put them in another subfolder name «config», or «options», or «settings». No ordinary user knows what «local» or «usr» means, nor should they ever have to. I’ve been using *nix CLIs for almost a decade and I don’t know nor care what the historical rationale was. It’s a bad system.
4 Answers 4
I think /opt is more standard in this sort of context. The relevant section in the Filesystem Hierarchy Standard is quoted below.
Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.
 Rationale The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here.
The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt.
Generally, all data required to support a package on a system must be present within /opt/, including files intended to be copied into /etc/opt/ and /var/opt/ as well as reserved directories in /opt.
The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution-installed and locally-installed software, especially in the case of fixed pathnames found in some binary software.
The structure of the directories below /opt/ is left up to the packager of the software, though it is recommended that packages are installed in /opt// and follow a similar structure to the guidelines for /opt/package. A valid reason for diverging from this structure is for support packages which may have files installed in /opt//lib or /opt//bin.
Note that /opt is mounted on / by default. If you have /home on a separate partition you might have chosen for a smaller size for / (I have a 50 GB partition). Installing big applications in /opt may not be possible in that case. You can always use symbolic links to bypass this issue.
You should only use /usr/local/share for files which are not specific to a particular architecture / OS version.
After that it’s up to you whether you distribute the files between the existing subdirs of /usr/local or if you create a new dedicated directory in /usr/local (but the latter will not already exist on the executable PATH , the LD_LIBRARY_PATH , nor the MANPATH ).
Thank you. So, if it is an analogy from Windows, it should be /usr/local/SPECIAL_APP and inside there should be its subdirectories, right?
@greenoldman: nope. No analogy will fit because Windows and Linux use different models: In windows, you usually keep all files in a single dir, where in Linux you usually split them over bin , share , lib , etc
Until /opt became common, the usual place was /usr/local/lib/ .
From what I read, /opt is pretty common, only not used widely, but this is not a surpise if you think of the amount of packages available in repositories.
When installing local applications, there are multiple options depending on how you want to access and update. Also should be noted that some methods look more like the system you already have and some are more ad-hoc. I would suggest that the «best» solutions are the ones that make things easier to manage.
I have split this answer based on the number of packages to make custom installs for. The splitting is based on my own experiences. These experiences weigh the time it takes to manage the packages and the risks of messing up something. I do not mean that I have the knowledge of common standards but mean this as a reference point to look when making the decision.
For only few packages,I would to put add-on packages in /opt , where they are out of the way of everything else so nothing can mess them up and they can mess something else up. This is the method I use on my NAS. This method however keeps the binaries off your PATH, so you will need to add them manually. This works well if there are only few packages to install, but becomes quite a mess if there are many.
Updating here is quite easy as you simply overwrite the directory.
- simple
- fast to setup
- no chance at affecting other parts of the system
- uninstall is as easy as install
- Becomes rather tedious if the number of packages to install is large
- Makes PATH look messy
For more than a few packages, I would recommend using the /usr/local/ and sym-linking the executable from /usr/local/bin or /usr/local/sbin depending on if you need root privileges. This saves you from changing your PATH every time something new is added so the PATH stays clean. This is the method I use on my Arch laptop for all non-pacman packages and AUR packages.
Updating is done by overwriting the package directory and checking that the symlink is still valid and fixing if it isn’t.
- Doesn’t make PATH messy
- Doesn’t affect the base system
- Still very simple to remove all add-ons and return to a clean base system
For many packages. As this isn’t the case you are wanting I will keep it brief. I would recommend splitting the package into bin , lib , share , etc. and installing them to /usr/local . This is to keep the structure clean. You can also specify who can write where and more. For example you don’t want people other than root modifying the executable.
Here the updating gets a little more tricky as you need to write to more than a single directory. I would recommend packaging the whole thing and letting the package manager handle the rest.
The share directory itself is for architecture independent files as noted in Faheem’s link and the architecture dependent files should go to lib , lib32 , lib64 , etc.
Linux usr local share
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr .
Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr . [28]
4.9.2. Requirements
The following directories, or symbolic links to directories, must be in /usr/local
| Directory | Description |
|---|---|
| bin | Local binaries |
| etc | Host-specific system configuration for local binaries |
| games | Local game binaries |
| include | Local C header files |
| lib | Local libraries |
| man | Local online manuals |
| sbin | Local system binaries |
| share | Local architecture-independent hierarchy |
| src | Local source code |
No other directories, except those listed below, may be in /usr/local after first installing a FHS-compliant system.
4.9.3. Specific Options
If directories /lib or /usr/lib exist, the equivalent directories must also exist in /usr/local .
/usr/local/etc may be a symbolic link to /etc/local .
Rationale
The consistency of /usr/local/etc is beneficial to installers, and is already used in other systems. As all of /usr/local needs to be backed up to reproduce a system, it introduces no additional maintenance overhead, but a symlink to /etc/local is suitable if systems want all their configuration under one hierarchy.
Note that /usr/etc is still not allowed: programs in /usr should place configuration files in /etc .
If the directory /usr/share/color exists as specified in this document, then the directory /usr/local/share/color must also exist, governed by the same rules as /usr/share/color .
Rationale
This usage allows the sysadmin a place to install color profiles manually when necessary.
4.9.4. /usr/local/share : Local architecture-independent hierarchy
The requirements for the contents of this directory are the same as for /usr/share .
[28] Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.