大多数使用自动工具的软件包都是用户级实用程序，或者至少足够高，完全在/ usr之下，或者足够低以至于完全低于/ usr。
我正在编写一个需要将一些文件安装到/ bin中的软件包，一些文件安装到/ sbin，/ usr / bin和/ usr / sbin中。它正在取代传统上放置在这些位置下的几个现有二进制文件。
它还需要在/ lib / security中安装PAM模块（显然/ usr / lib / security不起作用）。
现在问题是：默认配置的前缀似乎是/ usr / local（我可以控制我的configure.ac中的默认值），至少Gentoo Linux的默认值是--prefix = / usr（这是一个问题，因为它覆盖我在configure.ac中放入的任何默认值。
我简要介绍了其他类似的软件包是如何处理这个问题的。以下是我的发现：
我的问题是：
随意请求澄清我正在尝试做什么。请注意，如果我想保留与我正在替换的内容的兼容性，如果它曾用于发送二进制文件A和B，一个在/ sbin中，一个在/ usr / bin中，我想我只需要在这些地方或在至少有符号链接。 PAM模块也有固定的安装位置。
我显然会提出任何有用的答案。我是一个“接受的答案”我主要是在寻找建议“我应该做什么”，这个问题最简洁的解决方案是什么，如果适用的话，讨论选项和缺点，利弊。
答案 0 :(得分：3)
基本上，/和/usr层次结构之间的区别不是也不应该落在包的上游维护者手中（读：不是你的责任）。由于/应该只包含启动和使/usr可用所需的文件，因此这是/的行政决策。对于来自源的安装，此决定由安装程序进行，对于分发，由程序包维护者进行。
有关理由，假设某人正在尝试构建chroot环境。 / usr和/之间的区别在环境中是没有意义的，并且不会被创建。所有前缀都设置为/foo/bar/chroot，任何与$prefix混乱的配置脚本都可能导致奇怪的行为。对于像Debian打包帮助程序这样的脚本也是如此，它依赖于通常的$prefix语义来工作。
因此，最干净的解决方案是bash-4.1解决方案。您基本上有两个干净的选项：将软件包拆分为启动关键和非启动关键部分，或者让configure脚本为启动关键部分提供备用前缀，默认设置为{{ 1}}，将/保留为$prefix。
答案 1 :(得分：2)
此问题有两个不同的级别，您的问题似乎都适用于第二个含义（由* .spec文件生成的二进制包，或debian / rules或* .pkg文件。）目前为止作为autotools，你不关心。您不能尝试在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'平台配置的默认参数，但听起来你的问题实际上是关于二进制包的控制文件。