将二进制文件安装到 /bin、/sbin、/usr/bin 和 /usr/sbin 中，与 --prefix 和 DESTDIR 交互

发布于 2024-12-23 11:28:59 字数 1793 浏览 4 评论 0原文

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

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

它还需要在 /lib/security （显然是 /usr/lib /security 不起作用）。

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

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

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

我的问题是：

其他发行版的 --prefix 默认值是什么？我可以合理地假设它始终是 /usr 吗？我现在只关心 Linux，而不是 BSD。
上述哪种解决方案看起来最干净？您看到一些更好的解决方案吗？
上述解决方案有哪些潜在问题？这些问题有一些解决方案吗？
我可以将所有内容安装到 /bin 并创建兼容性符号链接。它会让问题变得更简单吗？
是否有其他一些常见构建系统可以接受低级系统实用程序，可以更好地满足我的要求？

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

我显然会投票赞成任何有用的答案。我是一个“接受的答案”，我主要是在寻求建议“我应该做什么”，问题的最干净的解决方案是什么，以及如果适用的话，对选项和缺点、优点和缺点的讨论。

原文

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.

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.

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

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 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.

My questions are:

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?

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.

I'm obviously going to upvote any useful answer. I an "accepted answer" I'm mostly looking for advice "what should I do", what's the cleanest solution to the problem and if applicable a discussion of options and drawbacks, pros and cons.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

橘香 2024-12-30 11:28:59

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

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

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

回复收藏 0 原文

蝶舞 2024-12-30 11:28:59

这个问题有两个不同的级别，您的问题似乎都适用于第二个含义（由 *.spec 文件生成的二进制包，或 debian/rules，或 *.pkg 文件。）关心，你不在乎。您不得尝试在configure.ac 中指定除/usr/local 之外的默认前缀。指定安装位置是在二进制包控制文件中完成的，而不是在configure.ac中完成的。使用 autoconf 生成的配置脚本的源发行版应该默认安装在 /usr/local 中，其他任何内容都是打包错误。

如果您希望拥有一个可供用户在特定平台上的特定位置轻松安装的源发行版，则可以在 tarball 中包含执行此操作的脚本。例如，您可能包含一个类似于以下内容的构建脚本：

#!/bin/sh

case $1 in
foo) args='--prefix=/usr --bindir=/bin --sysconfdir=/etc';;
bar) args='--prefix=/opt';;
*) args=;;
esac
$(dirname $0)/configure $args &&
make &&
make install

它将指定要为“foo”和“bar”平台配置的默认参数，但听起来您的问题确实是关于二进制包的控制文件。

There are two different levels to this question, and your questions all seem to apply to the second meaning (the binary package generated by your *.spec file, or debian/rules, or a *.pkg file.) As far as the autotools are concerned, you DO NOT CARE. You must not attempt to specify a default prefix other than /usr/local in your configure.ac. Specifying where things should be installed is done in the binary package control files, and NOT in configure.ac. The source distribution using the autoconf generated configure script should install in /usr/local by default, and anything else is a packaging error.

If you want to have a source distribution that the user can use to install easily in a particular location on a particular platform, it would be acceptable to include a script in the tarball that does so. For example, you might include a build script that looks something like:

#!/bin/sh

case $1 in
foo) args='--prefix=/usr --bindir=/bin --sysconfdir=/etc';;
bar) args='--prefix=/opt';;
*) args=;;
esac
$(dirname $0)/configure $args &&
make &&
make install

which would specify default arguments to configure for the 'foo' and 'bar' platforms, but it really sounds like your questions are about control files for binary packages.

回复收藏 0 原文

~没有更多了~