mjhjmtu

A software vendor has to create a Linux filesystem hierarchy standard (FHS) compliant Debian package.
What installation dir has to be used for binaries?

Software placed in /bin or /usr/bin may be overwritten by system upgrades. Is it okay to install binaries in that directories? Or are this directories reserved for the base system distributor?

/usr/local/bin is for software installed by the system administrator.
Everything under /usr/local must not be modified by system upgrades.
A vendor-provided Debian package may become part of the system upgrade procedure if it is downloaded from a package repository and this repository is registered with apt-add-repository. Therefore, I guess: No?

/opt/<vendor>/bin seems to be okay. But doesn't this directory have to be registered somewhere to avoid conflicts with other vendors? And how to integrate this directory in a FHS compliant way to make $PATH work?

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
top-level hierarchy

In practice, I've seen applications that do install .deb packages there as well. Ideally, /bin and /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 /usr/bin.

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

4.4.1. Purpose

This is the primary directory of executable commands on the

system.

4.4.2. Requirements

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 /usr/bin/my_binary

Another $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.