A while back I installed couchdb from source on my debian machine. It seemed to install okay and everything worked.

A few weeks later I wanted to upgrade and installed from a .deb using dpkg. Everything now seems to have been installed under /opt. It all seems to work fine, but I don't really understand why it's all been installed under /opt. It doesn't feel as "smooth" as when things were installed directly into /usr/local/bin and /etc and /var/log. It's more cumbersome to configure than when I previously just edited the configuration files that were installed under /etc/couchdb

Would someone mind explaining to me why installation to /opt is "a good thing" and why this is a better way of doing things than the previous installation which was from the source?

I know this is a rather vague question but I'm only competent with Linux not an expert and don't understand the thinking behind installing to /opt

  • Are you saying that a Debian package installed in /opt? If so, it is doing the wrong thing. I also have a Google Chrome application (not currently installed) that installed in /opt. Everything that is managed by the package system should go into the main system. Mar 26, 2011 at 6:52
  • On looking this more carefully, I could not find a clear statement in policy that Debian package installation (regardless whether it is official or not) should not install in /opt, though I have the strong impression that this should not be done, and there are various comments on the net that doing so is the wrong thing. If I find anything more definite I'll post it. AFAIK, Debian does not expect or require non-official packages to install in a different place from the official packages. Mar 26, 2011 at 7:11

4 Answers 4


The Filesystem Hierarchy Standard gives these definitions:

  • /opt : Add-on application software packages
  • /usr/local : Local hierarchy (for use by the system administrator when installing software locally)

The way I read that:

  • Standard system applications should go in /bin and /usr/bin (implied)
  • Third-party packages should go in /opt
  • Something should only be installed into /usr/local if the system administrator wants it to

By extension, if the sysadmin installs something using dpkg or rpm, it should not go into /usr/local by default.

So it's arguably doing the right thing.


Debian Policy says

9.1.2 Site-specific programs

As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts.

There is no such specific prohibition against /opt. Policy also adds

The location of all installed files and directories must comply with the Filesystem Hierarchy Standard (FHS), version 2.3, with the exceptions noted below, and except where doing so would violate other terms of Debian Policy.

and the File Hierarchy Standard says

The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use.

and then further down

Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.

Note that Policy is for Debian itself, but it generally corresponds to a best practice recommendation. The upshot, if I am reading this correctly, is that it is not Ok to install binary (deb) packages to /usr/local, but it is Ok to install in /opt as long as it does not interfere with the sysadmin's use of the space.

My personal opinion is that it is a bad idea to have deb packages in either /usr/local or /opt. I disagree with D4RIO when he says:

There is a Couchdb package for Debian (I mean, official), so if you downloaded another, it's Ok, it must be installed in /opt or /usr/local/bin either.

You don't generally want two different deb packages corresponding to the same software installed, and if they are actually the same package name, dpkg won't allow it anyway. Unofficial Debian packages of software available as an official package commonly (but not always) have the same name as the official ones; you just install one or the other, not both.

For what it is worth, I think putting deb packages in /opt is a bad idea, and the only recent occurrence of this I've seen is with Google Chrome. However, Google does not always follow best practices.

  • Completely agree that a package should not install to /opt, especially if it puts files elsewhere too like in /usr/bin. Imho /opt should contain completely self contained software so you can nuke it from orbit by simply just deleting it from /opt. Mar 26, 2011 at 16:59
  • Okay great responses thanks but it is installed to /opt by default. If not to /opt, then where should I install it to? And how to do so using dpkg?
    – user6055
    Mar 27, 2011 at 8:39
  • @Duke: If you can get the source of the deb package, you can rebuild the deb to install into the system like regular packages. This will require a little bit of work if you are not already familiar with the procedure, but imo that is the correct thing to do here. Mar 27, 2011 at 8:54
  • 1
    don't agree with this answer. There are plenty of situations where you want two versions of software installed, you can easily want a specific python for a specific application. A local sysadmin might want to package this python, where should it go? Locally installed (make install) software goes in /usr/local, 3rd packaged software goes in /opt/ - the definition of packages is kept broad: via dpkg, via installers, via PIP, via (insert packaging system of choice). I agree that it is good practice of self contained "provider/packages".
    – ashwoods
    Apr 12, 2012 at 11:34

/opt is for third-party software. There is a couchdb package for debian (I mean, official), so if you downloaded another, it's Ok, it must be installed in /opt or /usr/local/bin either.


Even though it's not Debian, the Fedora Packaging Guidelines are pretty clear about this:

…no Fedora package can have any files or directories under /opt or /usr/local…

The reason for packages not putting things in /opt is quite simple: As was pointed out before, the File Hierarchy Standard states that…

Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.

That is something that cannot be guaranteed by packages as an installation or update may modify such data.

I know Fedora is not Debian, but I guess that in this case, they are quite similar. Especially since Lintian, the package check tool for Debian, has a special error for this: dir-or-file-in-opt

You must log in to answer this question.