基本的に、/ の違いは そして /usr 階層は、パッケージの上流のメンテナーの手に渡ってはいけませんし、そうすべきではありません (読んでください:あなたの責任ではありません)。 /以降 起動と /usr の作成に必要なファイルのみを含める必要があります / をどうするかは管理上の決定です .ソースからのインストールの場合、この決定はインストーラーによって行われ、ディストリビューションの場合はパッケージのメンテナーによって行われます。
根拠として、誰かが chroot を構築しようとしているとします。 環境。 /usr と / の区別は、環境では意味がなく、行われません。すべてのプレフィックスは /foo/bar/chroot に設定されています 、および $prefix をいじる configure スクリプト 奇妙な行動を誘発する可能性があります。同じ引数は、通常の $prefix に依存する Debian パッケージング ヘルパーのようなスクリプトにも当てはまります。 動作するセマンティクス。
したがって、最もクリーンなソリューションは bash-4.1 です 解決。基本的に 2 つのクリーンなオプションがあります。パッケージを起動に重要な部分と起動に重要でない部分に分割するか、configure を スクリプトは、デフォルトで / に設定されている、起動に不可欠な部分の代替プレフィックスを提供します 、残 $prefix /usr として .
この質問には 2 つの異なるレベルがあり、あなたの質問はすべて 2 番目の意味 (*.spec ファイル、debian/rules、または *.pkg ファイルによって生成されたバイナリ パッケージ) に当てはまるようです。気にしないでください。 configure.ac で /usr/local 以外のデフォルトのプレフィックスを指定しようとしてはいけません。インストール先の指定は、configure.ac ではなく、バイナリ パッケージ コントロール ファイルで行われます。 autoconf によって生成された configure スクリプトを使用するソース配布は、デフォルトで /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' プラットフォーム用に構成するデフォルトの引数を指定しますが、あなたの質問はバイナリ パッケージの制御ファイルに関するものであるように思えます。