root以外のユーザーとしてソースから複数の（> 10）パッケージをビルドしてインストールしようとします（この問題を解決するには、値を選択してください--prefix=）。 2つの明確な選択は次のとおりです。
- 私のホームディレクトリを使う
etc/つまり、、、およびusr/同様のサブディレクトリがあり、var/各サブディレクトリには異なるパッケージのファイルが含まれます。しかし、ほとんどのパッケージは対話しないので、そのファイルを同じサブディレクトリに置くことは意味がありません。これは削除が難しいと思います。 - 各パッケージに別々のディレクトリを使用してください。、例えば
--prefix=$HOME/myfooapp。--prefix=$HOME/mybarlibこれにより、すべてが分離されたままになりますが、今私のホームディレクトリは、私が見たくないいくつかのサブディレクトリでいっぱいになります。パッケージもあります。するインタラクティブなので、同じ場所に一緒にいても大丈夫です（PATHを非常に長くする必要はありません）。
私が見逃した他のオプションはありますか？私の言葉は、私はできる
- オプション2に似ていますが、私のホームディレクトリのサブディレクトリにあります、例えば
--prefix=$HOME/opt/myfooapp、--prefix=$HOME/opt/mybarlib
これが私ができる最善ですか？
答え1
私はこれが一般的にウェブサイトのルールだと思います。長期にわたって実行されるインストールの場合は、$HOMEツリーに依存するのをやめ、/optを使用することを好みます。これは、適切な権限で/opt//を設定し、データなどの標準的な場所として使用する関連ディレクトリを設定することを意味していても、/optを使用することを好みます。 。あなたが指摘できるものの合理的な説明と一致します。https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
私にとっては、慣例に直接違反しないような努力に加えて、構造の使用に最大の影響を与えるのはサーバーの使用です。サーバーイメージを他の環境やソフトウェア/データに置き換える予定ですか？共有ファイルシステムを使用していますか、ソフトウェアを最適化するために特定のパーティションが必要ですか？このディレクトリをバックアップなどに含めますか？実行権限またはデータを他のユーザーアカウントと共有しますか？デフォルトのパスと共通のビルドフラグを拡張するために、共有シェルプロファイルログインでいくつかの環境変数を設定することを検討することもできます。
これが考える距離を与えることを願っています。もちろん、ローカルコンピュータにいる場合は、正しいと思われるすべての作業を実行してください。しかし、無視されるディレクトリツリーなので、/ optの使用を除外しないでください。 ^)
答え2
ついに私は決めた$HOME/opt/myfooapp。なぜなら：
- オプション2と3を使用すると、異なるパッケージのファイル層を分離できます。 /をrootとして使用するときに役立つパッケージマネージャがあるため、これは問題ではありません。私はそうではありません...
- オプション3だけが、私のホームディレクトリがパッケージのインストールに関連する複数のディレクトリに複雑になるのを防ぎます。
答え3
--prefix=$HOMEあまり複雑でPATHはなく、他の同様の情報ファイルの場所も使用され、よく書かMANPATHれたパッケージはとにかく各つま先を踏みません。