Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
I think /opt is more customary in this sort of context. – Faheem Mitha Sep 13 '11 at 8:56
@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 Sep 13 '11 at 10:22
Posted as requested. Thanks. – Faheem Mitha Sep 14 '11 at 1:41
@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 – MestreLion May 1 '13 at 4:06
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 – MestreLion May 1 '13 at 4:12
up vote 11 down vote accepted

I think /opt is more standard in this sort of context. See the relevant section in the Filesystem Hierarchy Standard.

share|improve this answer

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).

Have a look at the FHS

share|improve this answer
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 Sep 13 '11 at 17:38
@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 – MestreLion May 1 '13 at 4:09

Until /opt became common, the usual place was /usr/local/lib/<package>.

share|improve this answer
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. – greenoldman Sep 13 '11 at 11:07

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/<your package> 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


  • More work to setup
  • Removing only one package has some searching to do

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

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.

share|improve this answer
Giving advice based on number of packages is not useful; how do I know which group my package belongs to? – Alois Mahdal Nov 20 '15 at 14:40
Also, when you say "it is recommended", reference source or state clearly that it's your recommendation (I'm guessing the latter...?) – Alois Mahdal Nov 20 '15 at 14:41
And by the way, I don't see how in /opt there would be lesser chance of things messing up your app than when it's spread to /usr etc. Messing up other apps is mush more about naming things properly and not having bugs in install scripts. – Alois Mahdal Nov 20 '15 at 14:43
It is definitely about naming that makes things messed up. It is something that I have experienced in the past and that is why I like to keep my "extra" packages away from everything else. I still don't want it to make things look ugly. – Lauri Tšili Nov 26 '15 at 16:57
And yes you are correct about the "it is recommended" as you may see from my answer I have used "I would recommend" everywhere else. I have now fixed my spelling and cleared why I would recommend something. Again it is just my perspective and not meant as a definitive answer. – Lauri Tšili Nov 26 '15 at 17:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.