本质上，/和/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.