アプリケーションを/ usr / localまたは/ usr / local / shareに配置する必要がありますか？

「標準」とは何ですか-アプリケーション（バイナリだけでなく、配布全体）を/ usr / localまたは/ usr / local / shareに配置する必要があります。

たとえば、scalaやwekaなど、サンプル、バイナリ、ライブラリなどが含まれています。だからそれは

/usr/local/scala-2.9.1 

または

/usr/local/share/scala-2.9.1

私は唯一の管理者であるため、大したことではありませんが、自分の習慣ではなく、広く使用されているものを使用することを好みます。

重要：アプリを/ usr / local / bin、/ usr / local / libなどに分割する必要がある場合については、質問していません。むしろ、アプリケーション全体で1つのメインディレクトリを保持する必要がある場合について質問しています。

このような状況では、/ optの方がより標準的だと思います。Filesystem Hierarchy Standardの関連セクションを以下に引用します。

ディストリビューションはソフトウェアを/ optにインストールできますが、ローカルシステム管理者の同意なしにローカルシステム管理者がインストールしたソフトウェアを変更または削除してはなりません。

根拠アドオンソフトウェアに/ optを使用することは、UNIXコミュニティで確立された慣行です。System Vインターフェイス定義（第3版）に基づいたSystem Vアプリケーションバイナリインターフェイス[AT＆T 1990]は、ここで定義したものと非常によく似た/ opt構造を提供します。

Intel Binary Compatibility Standard v。2（iBCS2）も、/ optに同様の構造を提供します。

通常、システム上のパッケージをサポートするために必要なすべてのデータは、/ etc / opt /および/ var / opt /にコピーされるファイルと/ optの予約ディレクトリを含む/ opt /内に存在する必要があります。

特に一部のバイナリソフトウェアで見つかった固定パス名の場合、ディストリビューションでインストールされたソフトウェアとローカルにインストールされたソフトウェアの間で競合が発生する可能性があるため、/ optを使用したディストリビューションの軽微な制限が必要です。

/ opt /以下のディレクトリの構造はソフトウェアのパッケージャーに任されていますが、パッケージは/ opt //にインストールし、/ opt / packageのガイドラインと同様の構造に従うことをお勧めします。この構造から分岐する正当な理由は、/ opt // libまたは/ opt // binにインストールされたファイルがあるサポートパッケージのためです。

/usr/local/share特定のアーキテクチャ/ OSバージョンに固有ではないファイルにのみ使用してください。

後あなたは、既存のサブディレクトリ間でファイルを配布するかどうか、それはあなた次第だということ/usr/localか、中に新しい専用のディレクトリを作成した場合/usr/local（ただし、後者の意志がない既に実行可能に存在しPATH、LD_LIBRARY_PATH、またMANPATH）。

見ていFHSを

/opt一般的になるまで、通常の場所はでした/usr/local/lib/<package>。

ローカルアプリケーションをインストールする場合、アクセス方法と更新方法に応じて複数のオプションがあります。また、一部のメソッドはすでにあるシステムに似ていることや、アドホックなメソッドがあることに注意してください。「最良の」ソリューションは、物事を管理しやすくするものであることをお勧めします。

カスタムインストールを行うパッケージの数に基づいてこの回答を分割しました。分割は、私自身の経験に基づいています。これらの経験は、パッケージを管理するのにかかる時間と何かを台無しにするリスクを比較検討します。共通の標準の知識があるという意味ではありませんが、意思決定を行う際の参照ポイントとしてこれを意味します。

いくつかのパッケージについてのみ、アドオンパッケージをに配置し/opt、他のすべての邪魔にならないようにします。これは、NASで使用する方法です。ただし、この方法ではバイナリがPATHから除外されるため、手動で追加する必要があります。これは、インストールするパッケージが数個しかない場合はうまく機能しますが、多数ある場合は非常に混乱します。

ディレクトリを上書きするだけなので、ここでの更新は非常に簡単です。

長所：

• シンプルな
• セットアップが速い
• システムの他の部分に影響を及ぼす可能性はありません
• アンインストールはインストールと同じくらい簡単です

短所：

• インストールするパッケージの数が多い場合、かなり退屈になります
• 作りPATHルック乱雑を

いくつかのパッケージよりも、ルート権限が必要かどうかに応じて/usr/local/<your package>、/usr/local/binまたは/usr/local/sbin依存する実行可能ファイルを使用してシンボリックリンクすることをお勧めします。これにより、何か新しいものが追加されるたびにPATHを変更する必要がなくなり、PATHがクリーンなままになります。これは、pacman以外のすべてのパッケージとAURパッケージに対してArchラップトップで使用する方法です。

更新は、パッケージディレクトリを上書きし、シンボリックリンクがまだ有効であることを確認し、有効でない場合は修正することによって行われます。

長所

• PATH面倒なことはしない
• 基本システムには影響しません
• すべてのアドオンを削除し、クリーンなベースシステムに戻るのは非常に簡単です

短所：

• セットアップの作業が増える
• 1つのパッケージのみを削除するには、検索が必要です

多くのパッケージ用。これはあなたが望んでいるケースではないので、簡単に説明します。パッケージを、、などに分割しbin、libにshareインストールすることをお勧めし/usr/localます。これは、構造をきれいに保つためです。また、だれがどこに書き込むことができるかを指定することもできます。たとえば、ルート以外の人が実行可能ファイルを変更することは望ましくありません。

ここでは、複数のディレクトリに書き込む必要があるため、更新が少し難しくなります。全体をパッケージ化し、パッケージマネージャーに残りを処理させることをお勧めします。

シェア

shareFaheemの中で述べたように、ディレクトリ自体は、アーキテクチャに依存しないファイルのためにあるリンクに行くべきとアーキテクチャに依存するファイルlib、lib32、lib64、など