我一直在使用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中,这样人们可以更好地跟踪谁安装了什么。