Application Installation Directory – /usr/local vs /usr/local/share

applicationdirectory-structuresoftware installation

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 

/usr/local/scala-2.9.1

or 

/usr/local/share/scala-2.9.1

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.

Best Answer

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.

Related Question