Occasionally I install applications manually, rather than using
apt or another package manager.
What location (
/home/, etc.) is suggested by "best practices" for the installation of user applications?
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It only takes a minute to sign up.Sign up to join this community
That depends, really. If the application has a makefile, or for example for Python apps if the application uses distutils (e.g., has a
setup.py file), or a similar build/install system, you should install it into
/usr/local/. This is often the default behavior.
From what I understand,
/usr/local/ has a hierarchy that is similar to
/usr/. However, directories like
/usr/lib/ are usually reserved for packages installed via
apt. So a program expecting to get "installed" into
/usr/ should work fine in
If you just need to extract a tarball and run directly (e.g. Firefox) then put it into
/opt/. A program that just needs one directory and will get all files/libraries relative to that directory can get one directory for itself in
For reference, see the FHS.
It's good to remember that
/usr does not stand for user but rather unix system resources.
As such, I tend to figure that any distribution has the rights to stomp all over over contents of
/usr, and that my specific additions to the system go in
/usr/local, which I preserve before doing an upgrade.
Meanwhile, applications and other things go in
Some people feel comfortable putting stuff in
/home, though I rarely follow that convention.
All that said, I let the distribution package manager do things its way first, and then do the above when hand rolling stuff.
Install unstable programs like firefox devel in
/home/user/opt/ makes it a lot easier to remove, and no confusion for other users as to what version they should use... So if it is not a program for global use, install it in a subfolder in your home directory (
Never install programs in
/usr/, it is likely to cause chaos, things installed in
/usr/ is meant to be for distribution packages only. /usr/local/ is for packages locally compiled. And the structure works in exactly the same way! files in
/usr/local/ will be prioritized over files in
/opt/ should be used for installation of pre-compiled (binary) packages (Thunderbird, Eclipse, Netbeans, IBM NetSphere, etc) and the like. But if they are only for a single user they should be put in your home directory.
If you want to be able to run a program installed in a "weird" location (like
/home/user/opt/firefox/) without typing the whole path you need to add it to your
$PATH variable, you can do this be adding a line like this in your
The folder name should be the one where the executable file you need to run is located.
The Linux Filesystem Hierarchy Standard indicates
The original idea behind '/usr/local' was to have a separate ('local') '/usr' directory on every machine besides '/usr', which might be just mounted read-only from somewhere else. It copies the structure of '/usr'. These days, '/usr/local' is widely regarded as a good place in which to keep self-compiled or third-party programs. 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.
I usually have a folder named "Programs" in my home where I install those programs, strange enough (or not) they are all java stuff right now.
It has one great advantage for me, when I reinstall or change computers they get moved with the rest of my home. It has a clear disadvantage, those apps are only available to my user.
Use "checkinstall" to convert your alien package to a deb so that it is uninstallable using the package manager.
Do note that config files will often not be handled as config files (perhaps ignored, or perhaps treated as part of the app), and that pre- and post-install scripts sometimes get bungled, though it will usually warn you when it thinks the deb will have a bad pre- or post-install script.