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

Question

大多数使用自动工具的软件包都是用户级实用程序,或者至少足够高,完全在/ 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模块也有固定的安装位置.

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

Answer 1

/本质上，层次结构和层次结构之间的区别/usr不是也不应该掌握在软件包的上游维护者手中（请阅读：这不是您的责任）。由于/应该只包含启动和提供所需的文件/usr，因此将/. 对于源安装，此决定由安装程序做出，而对于发行版，则由软件包维护者做出。

出于基本原理，假设有人正在尝试构建一个chroot环境。/usr 和 / 之间的区别在环境中没有意义，不会进行区分。所有前缀都设置为/foo/bar/chroot，任何混乱的配置脚本$prefix都可能会引发奇怪的行为。同样的论点也适用于像 Debian 打包助手这样的脚本，它们依赖于通常的$prefix语义来工作。

因此，最干净的解决方案就是bash-4.1解决方案。您基本上有两个干净的选项：将包拆分为启动关键部分和非启动关键部分，或者让您的configure脚本为启动关键部分提供替代前缀，默认设置为/，保留$prefix为/usr。