Let's consult how Debian outlines /opt:
/opt/ Add-on application software packages Pre-compiled, non ".deb"
binary distribution (tar'ed..) goes here.
/opt/bin/ : Same as for top-level hierarchy
/opt/include/ : Same as
for top-level hierarchy
/opt/lib/ : Same as for top-level hierarchy
/opt/sbin/ : Same as for top-level hierarchy
/opt/share/ : Same as for
In practice, I've seen applications that do install
.deb packages there as well. Ideally,
/usr/bin should be reserved, and especially
/bin because it is defined as
Essential command executable (binaries) for all users (e.g., cat, ls, cp)
(especially files required to boot or rescue the system)
In practice, it's common to see debian packages from 3rd parties installing to
/usr/bin on Debian-based systems, probably because
/usr/bin is often part of the
PATH variable,so it can be easily launched via command-line. You've mentioned:"Software placed in /bin or /usr/bin may be overwritten by system upgrades". Upgrades target removal of specific files in
/usr/bin, so yes it may be overwritten but not unless some
.deb package specified removal of yours explicitly (as for example I've encountered with an applet package that removed older version of a dock that I use ). Upgrades can be dangerous if your software depends on specific binary version to be present in
Another common thing I've seen is symlinking: entry in
/usr/bin is a symlink to another location. This might be a viable option for integrating the binary into
$PATH as you mentioned in the question. Additionally, this goes along with what Debian's packaging manual regarding FHS states:
4.4. /usr/bin : Most user commands
This is the primary directory of executable commands on the
There must be no subdirectories in /usr/bin.
So, if you have application that expects subdirectories ( such as Python module with submodule directories ), best practice is to probably place the application elsewhere (in case of Python, that's
/usr/lib/python*/dist-packages directory) along with subdirectories, and make a symlink to
$PATH integration I've seen being done by some vendors is to edit user's
$PATH variable and append that to
~/.bashrc. (Yes, this is a poor practice, and I don't encourage it - merely stating the fact that's what I've seen being done).
"But doesn't this directory have to be registered somewhere to avoid conflicts with other vendors?" The mentioned Debian documentation doesn't say anything about registering the directory, so the answer is it doesn't have to, but if you do want to avoid a conflict, you could follow the schema
/opt/vendor/package-v-1.2/bin - that is specify package and release version, maybe a year as well.