我一直在使用Linux服务器已经有好几年了，我一直被Filesystem Hierarchy Standard弄糊涂了。 通常，我可以忍受混乱。 但是现在我正在开发我自己的Linux软件，我需要了解包pipe理者应该在哪里安装。
我非常确信/ opt是我的应用程序的最佳位置。 但是在调查了我的Debian文件系统之后，我不再确定：很多软件实际安装在/ usr / lib中！ 仅举几例：MySQL，MySQLWorkbench，Nautilus，Rythmbox …
根据FHS，/ usr / lib应该包含“用于编程和打包的库”和“包含不打算由用户或shell脚本直接执行的对象文件，库和内部二进制文件”（ 请参见此处 ）。
位于我的debian服务器的/ usr / lib中的许多软件不是库或内部二进制文件，而是完整的用户可执行软件！
我仍然希望将我的应用程序安装在/ opt中。 但是我真的很想知道这是否正确，最重要的是为什么 。
先谢谢你的好意，
埃里克。
理解文件系统Heirarchy标准的真正关键是知道它是为networking文件系统而devise的。
对于同一操作系统，发行版和体系结构的所有机器，您可以通过NFS共享/ usr并挂载它。
/ usr在networking堆栈初始化后重新装载。
/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 不同之处在于/usr是为了容纳作为系统一部分而安装的软件包。 从Debian / Ubuntu存储库，PPA等获得的软件包，请到这里。 虽然/opt适用于不通过发行版软件包分发过程分发的非捆绑第三方应用程序。
如果您分发.deb或.rpm软件包，并着眼于最终将您的软件包含在官方软件库中，则应安装到/usr 。 否则，请安装到/opt 。 无论哪种情况，您的应用程序都应该能够被编译为在任意位置运行（例如在GNU autotools的帮助下）。
我build议避免在/ opt下安装你的应用程序。 原因1：某些发行版默认没有/ opt原因2：/ usr / lib是库的标准path{如果其他应用程序需要使用您的库，则需要手动将库path添加到/ etc / ldconfig} / opt当您手动安装独立应用程序并且想要知道它们的位置时更方便
完全成熟的可执行文件位于/ usr / lib下的原因之一可能是它们是从其他脚本中使用的。 {例如，bash脚本不能直接使用API。 由于这个原因，一个常见的技巧是围绕这个API构build一个“包装器”，并将参数作为脚本的参数来推送}
您可以在<prefix>/lib安装库， <prefix>/lib <prefix>/bin二进制文件， <prefix>/include头文件， prefix/[share/]man手册页， <prefix>/lib/pkgconfig或<prefix/share/pkgconfig ， <prefix>/share/aclocal cmake .m4文件
然后让包pipe理员决定前缀。 如果你自己分发rpm的/ deb， /usr是一个前缀的好select。
./configure --prefix=~/.local/仍然可以工作，所以请不要在任何地方硬编码你的path！
一些库被包装到一些其他工具中，使它们也可执行并可用作库，但是它们仍然是库，并不在$ PATH中，因此可以将它们放在/ lib中。
请安装在/ opt。
太多的Linux应用程序与Windows开发人员在90年代所做的一样。
让我们安装我们的东西在C：\窗口，这样它很简单，很容易find（和稍快）。 然后来到15年的DLL地狱，因为不同的软件包需要不同版本的相同的库（在Windows中没有版本库）。
除非你正在编写实际的系统软件，否则把它放在/ opt中，这样人们可以更好地跟踪谁安装了什么。