将二进制文件安装到/bin、/sbin、/usr/bin 和/usr/sbin，与 --prefix 和 DESTDIR 交互 [英] Install binaries into /bin, /sbin, /usr/bin and /usr/sbin, interactions with --prefix and DESTDIR

问题描述

大多数使用 Autotools 的软件包是用户级实用程序或至少足够高的级别以完全位于 /usr 下，或者足够低以完全低于 /usr.

Most packages using Autotools are user-level utilities or at least high-enough level to be completely under /usr, or low enough to be entirely below /usr.

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

I'm writing a package that would need to install some files into /bin, some into /sbin, /usr/bin and /usr/sbin. It's replacing several existing binaries that are traditionally placed under those locations.

它还需要在/lib/security中安装一个PAM模块(显然/usr/lib/security是行不通的).

It also needs to install a PAM module in /lib/security (and obviously /usr/lib/security wouldn't work).

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

Now the problem is: default configure's prefix seems to be /usr/local. I can control that default in my configure.ac. And at least Gentoo Linux's default is --prefix=/usr. That's a problem because it overrides any defaults I put in my configure.ac.

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

I took a brief look at how other, similar packages are dealing with this issue. Here are my findings:

• bash-4.1 似乎安装到 /usr/bin，并且发行版构建脚本将 bash 二进制文件移动到 /bin
• Linux-PAM 在 configure.ac 中有 hacks，所以如果前缀是 /usr，它将使用 /sbin 和 >/lib 一些文件.它还将默认前缀设置为 /usr.我不确定如果用户传递不同的 --prefix 会发生什么.
• shadow-utils 如果前缀是 /usr，则将 exec_prefix 设置为 "".然后bin_PROGRAMS指向/bin，并且声明ubindir指向${prefix}/bin，这样ubin_PROGRAMS 指的是 /usr/bin.

• bash-4.1 seems to install into /usr/bin, and distro build scripts move the bash binary to /bin
• Linux-PAM has hacks in configure.ac so that if prefix is /usr, it's going to use /sbin and /lib for some of its files. It also sets the default prefix to /usr. I'm not sure what happens if the user passes a different --prefix.
• shadow-utils set exec_prefix to "" if prefix is /usr. Then bin_PROGRAMS refers to /bin, and ubindir is declared to point to ${prefix}/bin so that ubin_PROGRAMS refers to /usr/bin.

我的问题是:

• 其他发行版对 --prefix 的默认设置是什么?我可以合理地假设它总是 /usr 吗?我目前只关心 Linux，而不是 BSD.
• 以上哪种解决方案看起来最干净?您是否看到了一些更好的解决方案?
• 上述解决方案有哪些潜在问题?这些问题是否有一些解决方案?
• 我可以将所有内容安装到 /bin 并创建兼容性符号链接.它是否使问题变得更简单?
• 是否有其他一些通用构建系统可以被低级系统实用程序接受，从而更好地满足我的需求?

• What are other distros' defaults for --prefix? Can I reasonably assume it's always /usr? I'm only concerned about Linux at this point, not BSDs.
• Which of the above solutions seems the cleanest? Do you see some better solutions?
• What are potential problems with the above solutions? Are there some solutions to those problems?
• I'm fine with installing everything into /bin and creating compatibility symlinks. Does it make the problem simpler?
• Is there some other common build system that is acceptable for low-level system utilities that would better handle my requirements?

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

Feel free to ask for clarification of what I'm trying to do. Note that if I want to retain compatibility with what I'm replacing, if it used to ship binaries A and B, one in /sbin and one in /usr/bin, I think I just have to put replacements in those places or at least have symlinks. PAM modules also have a fixed install location.

我显然会赞成任何有用的答案.我是一个可接受的答案"我主要是在寻找我应该做什么"的建议，什么是最干净的问题解决方案，如果适用，讨论选项和缺点，优点和缺点.

推荐答案

本质上，/ 和 /usr 层次结构之间的区别不是也不应该在于包的上游维护者的手(阅读:不是你的责任).由于 / 应该只包含启动和使 /usr 可用所需的文件，所以 / 的内容是一个管理决定.对于从源代码安装，此决定由安装者决定，而对于分发，则由包维护者决定.

Essentially, the distinction between the / and the /usr hierarchies is not and should not lie in the hands of the packages' upstream maintainer (read: Is not your responsibility). Since / should only contain files necessary for booting and making /usr available, it is an administrative decision what goes to /. For installations from source, this decision is made by the installer, and for distributions, by the package maintainer.

作为一个基本原理，假设有人试图构建一个 chroot 环境./usr 和/的区别在环境中是没有意义的，不会做.所有前缀都设置为 /foo/bar/chroot，任何与 $prefix 混淆的配置脚本都可能导致奇怪的行为.同样的论点也适用于像 Debian 打包助手这样的脚本，它们依赖于通常的 $prefix 语义来工作.

For a rationale, suppose someone is trying to build a chroot environment. The distinction between /usr and / is meaningless in the environment, and will not be made. All prefixes are set to /foo/bar/chroot, and any configure script messing with $prefix is likely to induce strange behaviour. The same arguments goes for scripts like the Debian packaging helpers, which rely on the usual $prefix semantics to work.

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

The cleanest solution is therefore the bash-4.1 solution. You have basically two clean options: Split your package into boot-critical and non-boot-critical parts, or let your configure script offer an alternative prefix for the boot-critical parts, which is set by default to /, leaving $prefix as /usr.

这篇关于将二进制文件安装到/bin、/sbin、/usr/bin 和/usr/sbin，与 --prefix 和 DESTDIR 交互的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！