Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 28 down vote favorite
11

According to the Filesystem Hierarchy Standard, /opt is for "the installation of add-on application software packages". /usr/local is "for use by the system administrator when installing software locally". These use cases seem pretty similar. Software not included with distributions usually is configured by default to install in either /usr/local or /opt with no particular rhyme or reason as to which they chose.

Is there some difference I'm missing, or do both do the same thing, but exist for historical reasons?

share|improve this question
My understanding is that /usr/local is a local version of /usr file system, whereas /opt is place holder for misc stuff. – yasouser Apr 19 '11 at 13:11

5 Answers

up vote 18 down vote accepted

While both designed to contain files not belonging to the Operating System, /opt and /usr/local are not designed to contain the same set of files.

/usr/local is a place to install files built by the administrator usually by using the make command. The idea is to avoid clashes with files that are part of the operating systems that would either be overwritten or overwrite the local ones otherwise. eg. /usr/bin/foo is part of the OS while /usr/local/bin/foo is a local alternative.

All files under /usr are shareable between OS instances although this is rarely done with Linux. This is a part where the FHS is weak, as /usr is defined to be read-only but /usr/local/bin need to be read write for local installation of software to succeed. The SVR4 file system standard which was the main source of inspiration for the FHS is recommending to avoid /usr/local and use /opt/local instead to avoid this contradiction. /usr/local is a legacy from the original BSD. At that time, the source code of /usr/bin OS commands were in /usr/src/bin (or /usr/src/usr.bin) while the source of commands developed locally were in /usr/local/src and their binaries in /usr/local/bin. There was no notion of packaging (outside tarballs).

On the other hand, /opt is a directory to install unbundled packages each in their own subdirectory. They are already built whole packages provided by an independent third party software distributor. For example someapp would be installed in /opt/someapp, one of its command would be in /opt/someapp/bin/foo, its configuration file would be in /etc/opt/someapp/foo.conf, and its log files in /var/opt/someapp/logs/foo.access.

share|improve this answer
/usr/local, for self, inhouse, compiled and maintained software. /opt is for non-self, external, prepackaged binary/application bundle installation area. Hmmm...we do not have C:\program files for everything ;-) – Nikhil Mulley Feb 2 '12 at 12:49
up vote 11 down vote

The basic difference is that /usr/local is for software not managed by the system packager, but still following the standard unix deployment rules.

That's why you have /usr/local/bin, /usr/local/sbin /usr/local/include etc...

/opt on the other hand is for software that doesn't follow this and is deployed in a monolithic fashion. This usually includes commercial and/or cross-platform software that is packaged in the "Windows" style.

share|improve this answer
1  
I disagree about your monolithic point. The FHS standard says packages installed in /opt subdirectories must have their host specific files be installed outside /opt, respectively under /etc/opt/package for configuration files and /var/opt/package for logs, spool and similar. /opt is actually closer to the unix deployment rules than /usr/local, which put everything under a directory that should be read-only but can't be for obvious reasons. – jlliagre Apr 4 at 9:03
up vote 6 down vote

They are very similar indeed, and the use of one or the other is more a matter of opinion. Linux journal had this point/counterpoint discussion about this exact topic here.

share|improve this answer
Oh dear. I didn't mean to drag myself into a "holy war". – Patches Apr 18 '11 at 15:01
up vote 3 down vote

For me, personally, it's what Bill said in @philfr's link:

On a development system, or a sandbox, having an /opt directory where you can just toss things and see if they work makes a whole lot of sense. I know I'm not going to go through the effort of packaging things myself to try them out. If the app doesn't work out, you can simply rm the /opt/mytestapp directory and that application is history. Packaging may make sense when you're running a large deployment (there are times when I do package apps), but lots of times, it's nice to toss stuff in /opt.

Unfortunately, most make install scripts pushes files into /usr/local instead of just making a symlink there :-/

share|improve this answer
1  
What would be the point? If you are going to make the symlink anyway, why not just put the original file there in the first place? – Let_Me_Be Apr 18 '11 at 9:54
1  
Just to comment on the make install target pushing files into /usr/local; this functionality is easily changeable by passing a --prefix= command line parameter to the ./configure script, or if there is no ./configure script, you can pass a parameter to the make target like so: make --prefix=/usr install. – Sean C. Apr 18 '11 at 11:45
Is /opt a standard directory included in $PATH? I know /usr/local is. – ultrasawblade Apr 18 '11 at 14:13
@Let_Me_Be the benefit would be that it's very easy to keep older versions. Let's say I have 2 versions of 'foo', located in /opt/foo-1.1 and /opt/foo-1.2. When I upgrade, foo symlink in /usr/local/bin points to foo-1.2. If for some reason I need to rollback, I just replace the symlink with one that points to foo-1.1 instead. If 1.2 is okay after several weeks, a quick rm -rf /opt/foo-1.1 removes the older version quickly and cleanly. – pepoluan Apr 18 '11 at 14:41
@Sean indeed. but sometimes lots of crud gets sent there, too. I'd rather have the cruds not littering my /usr/local – pepoluan Apr 18 '11 at 14:42
show 1 more comment
up vote 2 down vote

First, I don't think there is a strict answer; different adminstrators will have different opinions, according to their background. Historically, /usr/local came first; it was the convention in Berkley, IIRC. At one point during the development of System V, if I'm not mistaken (this is all a long time ago, and I didn't take notes), there was a decision or a desire to be able to mount /usr read-only, which meant you couldn't add new software to it; that may have been why /opt was invented. As it happens, there was just so much existing software that did write to /usr that that idea never really got off the ground.

My personal preference is /opt, with a separate subdirectory for each product; this makes removing a product a simple case of rm -fr. But if all of your software is installed via a good package manager, it doesn't matter, and if the software you install doesn't strictly obey these conventions, and writes configurations and such somewhere under /usr, it doesn't matter either, although for the opposite reasons.

share|improve this answer

Your Answer

 
discard

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.