> Зачем выносить /var/lib(раз уж до сих пор, насрав на FHS, туда суют базы мускуля, постгри и ко)...

Мне вот самому стало интересно и я решил ознакомиться с этим документом.
http://www.pathname.com/fhs/pub/fhs-2.3.pdf
33-34 страницы:

5.8. /var/lib : Variable state information
5.8.1. Purpose
This hierarchy holds state information pertaining to an application or the system. State information is data that
programs modify while they run, and that pertains to one specific host. Users must never need to modify files in
/var/lib to configure a package’s operation.
State information is generally used to preserve the condition of an application (or a group of inter-related
applications) between invocations and between different instances of the same application. State information
should generally remain valid after a reboot, should not be logging output, and should not be spooled data.
An application (or a group of inter-related applications) must use a subdirectory of /var/lib for its data. There
is one required subdirectory, /var/lib/misc, which is intended for state files that don’t need a subdirectory;
the other subdirectories should only be present if the application in question is included in the distribution. 3
/var/lib/<name> is the location that must be used for all distribution packaging support. Different
distributions may use different names, of course.

Почему хранение БД в "/var/lib/mysql", по вашему, оскверняет FHS?
Я так понимаю, вы думаете, что БД должна хранится в "/srv/mysql"?

3.16. /srv : Data for services provided by this system
3.16.1. Purpose
/srv contains site-specific data which is served by this system.
This main purpose of specifying this is so that users may find the location of the data files for particular
service, and so that services which require a single tree for readonly data, writable data and scripts (such as
cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users’
home directory.
The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on
how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www,
and cvs. On large systems it can be useful to structure /srv by administrative context, such as
/srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program
should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv.
However /srv should always exist on FHS compliant systems and should be used as the default location for
such data.

С английским у меня не очень, но в чём отличие переменных данных не редактируемых пользователем данных и site-specific данных обслуживающих эту систему?
Тут, как по мне, сам HFS вносит путаницу. Тогда уже и почту в /srv - это же тоже "site-specific данные обслуживающие эту систему", или нет?

Но больше всего бросилось в глаза это.

14. This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but
require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and
/lib a symlink to one of them.

Вот это вот действительно пример массового забивания болта на FHS.