linux – GNU Autotools:将二进制文件安装到/ bin,/ sbin,/usr/bin和/usr/sbin,与–prefix和DESTDIR交互

前端之家收集整理的这篇文章主要介绍了linux – GNU Autotools:将二进制文件安装到/ bin,/ sbin,/usr/bin和/usr/sbin,与–prefix和DESTDIR交互前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

大多数使用自动工具的软件包都是用户级实用程序,或者至少足够高,完全在/ usr之下,或者足够低以至于完全低于/ usr.

我正在编写一个需要将一些文件安装到/ bin中的软件包,一些安装到/ sbin,/usr/bin和/usr/sbin中.它正在取代传统上放置在这些位置下的几个现有二进制文件.

它还需要在/ lib / security中安装PAM模块(显然/usr/lib / security不起作用).

现在问题是:默认配置的前缀似乎是/usr/local(我可以控制我的configure.ac中的默认值),至少Gentoo Linux的默认值是–prefix = / usr(这是一个问题因为它会覆盖任何默认值我输入了我的configure.ac).

我简要介绍了其他类似的软件包是如何处理这个问题的.以下是我的发现:

> bash-4.1似乎安装到/usr/bin中,而发行版构建脚本将bash二进制文件移动到/ bin
> Linux-PAM在configure.ac中有黑客攻击,因此如果前缀是“/ usr”,它将对其某些文件使用“/ sbin”和“/ lib”.它还将默认前缀设置为“/ usr”.我不确定如果用户传递了不同的–prefix会发生什么.
> shadow-utils将exec_prefix设置为“”,前缀是“/ usr”.然后bin_PROGRAMS引用“/ bin”,并声明ubindir指向“${prefix} / bin”,以便ubin_PROGRAMS引用“/usr/bin”

我的问题是:

> –prefix的其他发行版默认值是什么?我可以合理地假设它总是/ usr吗?我现在只关心Linux,而不是BSD.
>以上哪种解决方案看起来最干净?你看到一些更好的解决方案吗?
>上述解决方案存在哪些潜在问题?这些问题有解决方案吗?
>我可以将所有内容安装到“/ bin”并创建兼容性符号链接.它会使问题更简单吗?
>是否有一些其他常见的构建系统可供低级系统实用程序使用,以便更好地满足我的要求?

随意请求澄清我正在尝试做什么.请注意,如果我想保留与我正在替换的内容的兼容性,如果它曾用于发送二进制文件A和B,一个在/ sbin中,一个在/usr/bin中,我想我只需要在这些地方或在至少有符号链接. PAM模块也有固定的安装位置.

我显然会提出任何有用的答案.我是一个“接受的答案”我主要是在寻找建议“我该怎么做”,这个问题最简洁的解决方案是什么,如果适用的话,讨论选项和缺点,利弊.

最佳答案
从本质上讲,/和/ usr层次结构之间的区别不是也不应该落在包的上游维护者手中(读:不是你的责任).由于/应该只包含引导和/ usr可用所需的文件,因此管理决定是什么.对于来自源的安装,此决定由安装程序进行,对于分发,由程序包维护者进行.

理由是,假设有人正在尝试构建chroot环境. / usr和/之间的区别在环境中是没有意义的,并且不会被创建.所有前缀都设置为/ foo / bar / chroot,任何与$prefix混乱的配置脚本都可能导致奇怪的行为.对于像Debian打包帮助程序这样的脚本也是如此,它依赖于通常的$前缀语义来工作.

因此,最干净的解决方案是bash-4.1解决方案.您基本上有两个干净的选项:将您的软件包拆分为启动关键和非启动关键部分,或者让您的配置脚本为启动关键部分提供备用前缀,默认设置为/,将$prefix保留为/ usr中.

猜你在找的Linux相关文章