When installing user applications, where do «best practices» suggest they be located?
Occasionally I install applications manually, rather than using apt or another package manager. What location ( /usr/ , /usr/local/ , /opt/ , /home/ , etc.) is suggested by «best practices» for the installation of user applications?
Liking to install things from source every so often, I wrote a little tool to do it which does the changes to your shell startup file on its own (and also modify your library prefix, if you ask it, for programs that depend on shared libraries). Not very feature rich, but it works 99% of the time.
Great discussion on the distinction between /opt and /usr/local : unix.stackexchange.com/q/11544/11917
6 Answers 6
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/bin/ and /usr/lib/ are usually reserved for packages installed via apt . So a program expecting to get «installed» into /usr/ should work fine in /usr/local/ .
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 /opt/ .
You can install things inside ~ (your home directory), but that will make an application accessible only to one user. Other users on your system will have to install and maintain their own installations of that software. As for best practices on installing applications install your home directory, I believe there aren’t as strong guidelines because you won’t interfere with system packages.
Is it wrong to install apps that are ‘unzipped from tar’ under /home/ubuntu/myapp — what diff does this made compared with /opt/myapp?
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 /opt .
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.
It’s worth remembering that ‘unix system resources’ is a renaming performed AFTER ‘/home’ was added. In the old, old, old days (Unix Version 6 et.al.) you would see directories like /usr/jimmy, /usr/siobhan, /usr/ahmed, etc. because the «user» directories were stored in /usr.
@Seth I think it’s ‘optional’ — it was originally for software that wasn’t part of a default installation.
/usr is User . That was because linux users were developers. First as it started to devide into devs and users the /home dir was introduced. And then someone had the idea to say it means Unix System Resources , which doesn’t really makes sense, because we have the Unix system Resources in /dev
Correct, /usr is a backronym. The purpose has changed since the days Unix was running on a PDP-7 back in 1969.
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 ( /home/user/ ).
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 /usr/ .
/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 /home/user/.profile
export PATH=/home/user/opt/firefox:$PATH The folder name should be the one where the executable file you need to run is located.
Where does apt-get install packages to?
Whether you are a Linux veteran or just starting with Linux, you must have used apt-get or seen it being used somewhere. It is the primary way to install packages and dependencies on Ubuntu. In simpler terms, apt-get is the go-to of every Linux user when looking to set up software on their computer. This gives rise to a new question – where does apt-get install these packages to? Where do the files go, and how can one access them? In this guide, we will find out the answers to these questions.
Ubuntu Filesystem Layout
Before we get into the technicalities of the matter, let us start by acquiring a basic understanding of the Filesystem Hierarchy Standard, shortly known as FHS. All Linux distributions get their directory structure and contents from Filesystem Hierarchy Standard. We will briefly go over some parts that are crucial to understanding where apt-get install packages are and why so.
FHS is not considered to be some authority on directory structure and contents for absolutely every Linux distribution, but it is generally the most common standard of file layout. All directories and files in FHS appear under ‘/’ – the root directory. Let’s take a look at some commonly used directories.
- /bin directory holds the primary command binaries.
- /dev directory contains device files.
- /etc directory has host-specific configuration files.
- /home folder contains the user’s personal settings and saved files.
A non-profit organization known as Linux Foundation maintains the Filesystem Hierarchy Standard, and the last update (version 3.0) was made on June 3, 2015.
Now that we have gotten a better understanding of how the general Linux filesystem is structured and how it operates, we are ready to learn how apt-get makes use of this very structure to install packages and dependencies.
Package Management
All operating systems and Linux distributions come with a package manager. These package managers are responsible for installing and removing software from the computer and maintaining them. They give the user more control over what kind of programs they wish to run on the system and make their installation possible.
In Ubuntu (and Debian), dpkg is the package manager that most people use. You can manage packages with .deb extensions through dpkg. Discussing this utility is pertinent to our subject since we will be using it to find apt-get installs packages. “Aptitude” is the more user-friendly way to use dpkg as it provides a front-end to the users. Let us look at how dpkg works in Ubuntu, its syntax, and how you can use it to find out where apt-get installs packages.
The general syntax of this command is as follows.
Another common method of using it is:
You can install a package on your Linux system by running the following simple dpkg command.
We will understand how one can use dpkg and apt-get to install packages and learn where the packages are installed in the following sections.
How does apt-get work?
By this point, we all know that apt-get can be used to install, remove, and upgrade Linux packages. We also learned that it serves as the front-end for dpkg, the native package management utility for Ubuntu and Debian. But how does it really work? And what happens to the files that are installed by it? Let’s find out!
Let us start by installing a test package called ack. For this purpose, we will use apt-get, and later we will trace the files installed by it to their specific locations.
Go ahead and start a new Terminal window through the Activities menu or pressing Ctrl + Alt + T on your keyboard. The next step is to make sure you have the multiverse repository added. Without that, you cannot install ack. You are, obviously, free to use any other package of your choice.
So, to add the repository, run the following command in the Terminal.
Once that is out of the way, we move on to installing the package.
(Note that instead of ack-grep, ack was installed. This is why we will be modifying the next commands we execute)
The installation will be complete within a few seconds. Having done that, we now investigate the package with the help of our package manager, dpkg. We will find out where the files of the package were installed and how to access them.
Recall the general syntax of the dpkg command that we described in the earlier sections. Here, we will be using a variation of that command to list the files in the installed package.
To list the contents of a package, we use the -L operator with the dpkg command. Run the command given below to see the files.
As you can see in the image, all the package manager installed files are shown along with their addresses on the computer.
In addition to that, some files are created or modified by pre/postrm and pre/postinstall scripts included in the installed package. You can view these scripts in the following directory.
Additional Information
Now that we have covered the meat of the tutorial, we will add some additional pieces of information for those that are curious about learning more.
Let’s say, for example, you want to use dpkg to extract all the files of a package in the current directory. You can do this by running the following simple command.
You can also get a hold of the files such as preinst, postrm, postinst, and more by the command given below.
This will extract said files into the current directory as well.
Conclusion
With that being said, we conclude this guide. We learned several things about apt-get today. We saw the Filesystem Hierarchy Standard, how the Ubuntu package manager works, and finally, how we can find where apt-get installs packages to.
About the author
Zeeman Memon
Hi there! I’m a Software Engineer who loves to write about tech. You can reach out to me on LinkedIn.