Why does software install itself in /usr/lib?

Solution 1:

The real key to understanding the Filesystem Heirarchy Standard is knowing that it is designed with network filesystems in mind.

For every machine of the same OS, release, and architecture, you can share /usr via NFS and mount it.
/usr is (re)mounted after the network stack is initialized.

/var <-- local, r/w optimized
/usr <-- can be mounted over network, possibly even read-only!
/opt <-- local, read mostly
/etc <-- local, read mostly
/srv <-- local, r/w optimized

/home <-- either/or

Solution 2:

The difference is that /usr is meant to hold packages installed as part of the system. Packages you get from the Debian/Ubuntu repositories, PPAs, etc., go here. While /opt is meant for unbundled third party applications that are not distributed through the distribution's package distribution process.

If you distribute .deb or .rpm packages, with an eye toward eventually getting your software included in the official repositories, you should install to /usr. Otherwise install to /opt. In either case, your application should be able to be compiled to run in any arbitrary location (e.g. with the help of the GNU autotools).

Solution 3:

You install your libraries in <prefix>/lib , your binaries in <prefix>/bin, your header files in <prefix>/include, man pages in prefix/[share/]man, pkgconfig files in <prefix>/lib/pkgconfig or <prefix/share/pkgconfig, your cmake .m4 files in <prefix>/share/aclocal

Then let package manager decide on the prefix. If you are distributing rpm's/deb's yourself, /usr is a good choice for a prefix.

./configure --prefix=~/.local/ Should still work, so don't go hardcoding your path anywhere please!

Some libraries are wrapped into some other tool that makes them also executable and usable as a library, but they are still libraries, and not in your $PATH, so it is ok to puth them in /lib I guess.