What is the conventional install location for applications in Linux?

Solution 1:

According to the Filesystem Hierarchy Standard, there are several places that are acceptable, depending on the application. I'm quoting from it extensively here.

• bin is short for "binary" of course

• sbin is short for "server binary", otherwise defined as:

  Utilities used for system administration (and other root-only commands)

• /usr is for shareable, read-only data, and should be shareable between various FHS-compliant hosts (if you have lots of machines on your network, and they're all the same architecture, you should be able to share a single /usr folder with every machine on the network)

• /usr/local is for use by the system administrator when installing software locally (ie, for applications installed only on this machine, not on every machine on the network).

Taking these together:

• /usr/bin is the primary directory of executable commands on the system.
• /usr/sbin is for any non-essential binaries used exclusively by the system administrator.
• System administration programs that are required for system repair, system recovery, mounting /usr, or other essential functions must be placed in /sbin instead (ie, the things you need to access in order to mount /usr/sbin go in /sbin)
• Likewise, essential user commands that may be needed before /usr is mounted go in /bin
• Anything installed only on the local machine should go in /usr/local/bin or /usr/local/sbin

There's one other use for /usr/local though. Most things that you install through your distro's package manager will be placed under /usr; many people put things they've compiled by hand under /usr/local instead. This keeps them out of the way of the package management system and lets you spot what you installed from the distro (and don't need to back up because you can grab it again) and what you compiled by hand; it also lets you run different versions at the same time (eg, /usr/bin/firefox vs /usr/local/bin/firefox).

Just when you thought things were settled, there's one other place, which is probably the closest equivalent of c:\Program Files - /opt:

/opt is reserved for the installation of add-on application software packages.`

/opt is probably the closest equivalent to c:\program files, in that it's the one place you'd expect to find an application with all its files together in one folder, rather than scattered across /usr/bin, /var, and /etc. It's usually only used by very large packages, but in this case, given that Netbeans wants to have its own folder, it probably makes the most sense to put it under /opt/netbeans

Solution 2:

Really it comes down to personal preference. I'll explain mine for what it's worth.

/usr, /usr/bin are usually places for software installed by the system to be installed. When I install things myself, I install them in one of several places:

1. If it's a script or small program only I will use, I install it in ~/bin - this is where most of my stuff ends up.
2. If it's something like you described (NetBeans) with a full file tree of its own, I install it in /opt
3. If it's a single executable, I install it in /usr/local/bin

Why do I distinguish between #2 & #3? No idea, it's just a habit that I've developed over time. It does work out that /opt usually ends up becoming a deep tree of files, but has only 2 or 3 actual 'things' installed. At this moment, I have lampp and lotus notes installed in opt, 2 directories that each have rather large trees beneath them. In /usr/local/bin, I have 20 or 30 entries, but no subdirectory.

I don't install things in /usr/bin or /usr/sbin because I like to keep things that I add manually (not part of simply installing from the standard repository) separate.

Solution 3:

While the Filesystem Hierarchy Standard does provide some guidance. I've found that most distributions like to install packages into /usr/share.

Because of this, I've adopted the practice of installing any application not installed via package manager (rpm / apt-get / emerge) in /usr/local. This allows me to keep applications and libraries that aren't managed via package management separate from those that are.

It's a technique that has helped me manage my system under both Fedora Core and Gentoo.