While both are designed to contain files not belonging to the operating system, /opt
and /usr/local
are not intended to contain the same set of files.
/usr/local
is a place to install files built by the administrator, typically by using the make
command (e.g., ./configure; make; make install
). The idea is to avoid clashes with files that are part of the operating system, which would either be overwritten or overwrite the local ones otherwise (e.g., /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 slightly self-contradictory, as /usr
is defined to be read-only, but /usr/local/bin
needs to be read-write for local installation of software to succeed. The SVR4 file system standard, which was the FHS' main source of inspiration, is recommending to avoid /usr/local
and use /opt/local
instead to overcome this issue.
/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
and /usr/src/usr.bin
, while the source of locally developed commands was 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 for installing unbundled packages (i.e. packages not part of the Operating System distribution, but provided by an independent source), each one in its own subdirectory. They are already built whole packages provided by an independent third party software distributor. Unlike /usr/local
stuff, these packages follow the directory conventions (or at least they should). For example, someapp
would be installed in /opt/someapp
, with one of its command being /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
.
rpmlint
is a tool to check RPMs against some sort of packaging policy. Its configuration is typically distribution dependant and it checks packages against the particular distribution policy. Checking your own packages is fine as long as this is what you want.
If your policy differs from the distribution policy, you either have to configure rpmlint
accordingly, refrain from using it or ignore the specific errors.
The following should do the trick when added to /etc/rpmlint/config
or ~/.config/rpmlint
(not tested):
addFilter("E: dir-or-file-in-usr-local")
Sources:
Best Answer
Considering
/home
is generally used for end users' home directories, it is not a good practice to mount general use filesystems in/home
, as it may lead to a confusion later on with other sysadmins, whom, one day, will take over this system from you upon your departure for greener pastures.I am not familiar with seafile-server, but assuming it is a 3rd party application and its related directory tree, then it is fine to mount it under
/opt
.Having said all of this, mounting a directory on either
/home
or/opt
, technically has no difference. Just make sure you are not doing nested mounts, i.e., mounting a filesystem over another filesystem. Even though this is technically possible, it lends itself to problems in the future, if the higher level filesystem decides to go bust one day. I know it is not your question, but just make sure, wherever you are mounting this filesystem under, is not a mounted filesystem, but a plain directory on root filesystem (i.e., under "/").