/ optと/ usr / localの違いは何ですか？

よるとはFilesystem Hierarchy Standard、/opt「アドオンアプリケーションソフトウェアパッケージのインストール」のためです。 /usr/local「ソフトウェアをローカルにインストールするときにシステム管理者が使用するため」です。これらのユースケースは非常によく似ています。通常、ディストリビューションに含まれていないソフトウェアは、デフォルトで、選択した特定の韻や理由のいずれ/usr/localか/optでインストールされるように構成されています。

私が欠落しているいくつかの違いがありますか、または両方が同じことをしますが、歴史的な理由で存在しますか？

両方のオペレーティングシステムに属していないファイルを含むように設計されており、一方で/optと/usr/local同じファイルのセットを含むように意図されていません。

/usr/local通常はmakeコマンド（例：）を使用して、管理者が作成したファイルをインストールする場所./configure; make; make installです。これは、オペレーティングシステムの一部であるファイルとの衝突を回避することです。これらのファイルは、ローカルのファイルを上書きまたは上書きします（たとえば、/usr/bin/fooOSの一部で/usr/local/bin/fooあり、ローカルの代替です）。

以下のすべてのファイル/usrはOSインスタンス間で共有可能ですが、これはLinuxではめったに行われません。これは、/usr読み取り専用であると定義されているように、FHSがわずかに矛盾する部分ですが、/usr/local/binソフトウェアのローカルインストールを成功させるには読み取り/書き込みが必要です。FHSの主なインスピレーションの源であったSVR4ファイルシステム標準は、この問題を回避するために/usr/local、/opt/local代わりに回避して使用することを推奨しています。

/usr/local元のBSDからの遺産です。当時、/usr/binOSコマンドのソースコードはとに/usr/src/binあり/usr/src/usr.bin、ローカルで開発されたコマンドのソースはに/usr/local/srcあり、そのバイナリはにありました/usr/local/bin。パッケージ化の概念はありませんでした（tarball以外）。

一方、/optバンドルされていないパッケージ（つまり、オペレーティングシステムの配布の一部ではないが、独立したソースによって提供されるパッケージ）をインストールするためのディレクトリであり、それぞれが独自のサブディレクトリにあります。これらは、独立したサードパーティのソフトウェアディストリビュータによって提供されるパッケージ全体が既に構築されています。/usr/localものとは異なり、これらのパッケージはディレクトリ規則に従います（または、少なくともそうすべきです）。たとえば、someappにインストールされ/opt/someapp、そのコマンドの1つが/opt/someapp/bin/foo、その構成ファイルがに、/etc/opt/someapp/foo.confログファイルがになり/var/opt/someapp/logs/foo.accessます。

基本的な違いは、/usr/localソフトウェアがシステムパッケージャーによって管理されていないが、標準のUNIX展開規則に従っていることです。

あなたが持っている理由です/usr/local/bin、/usr/local/sbin /usr/local/includeなど...

/opt一方、これに従わず、モノリシックに展開されるソフトウェア向けです。これには通常、「Windows」スタイルでパッケージ化された商用および/またはクロスプラットフォームソフトウェアが含まれます。

実際、それらは非常に似ており、どちらを使用するかは意見の問題です。Linuxジャーナルには、この正確なトピックに関するこのポイント/カウンターポイントディスカッションがありました。

私にとって、個人的には、@ philfrのリンクでビルが言ったことです。

開発システムまたはサンドボックスでは、/ optディレクトリを使用して、物を投げて、それらが機能するかどうかを確認することができます。試してみるために自分で物事をパッケージ化する努力をするつもりはないことを知っています。アプリが動作しない場合は、単に/ opt / mytestappディレクトリをrmすると、そのアプリケーションが履歴になります。大規模な展開を実行している場合（アプリをパッケージ化する場合もあります）、パッケージングは​​理にかなっている場合がありますが、多くの場合、/ optでトスするのは良いことです。

残念ながら、ほとんどのmake installスクリプト/usr/localは単にそこにシンボリックリンクを作成する代わりにファイルをプッシュします：-/

まず、厳密な答えがあるとは思わない。背景に応じて、管理者が異なれば意見も異なります。歴史的に、/usr/local最初に来ました。これは、IIRCのバークレーでのコンベンションでした。System Vの開発中のある時点で、私が間違えなかった場合（これはずっと前であり、メモを取っていませんでした）、/usr読み取り専用にマウントできるようにするという決定または要望がありました。つまり、新しいソフトウェアを追加できませんでした。それ/opt が発明された理由かもしれません。偶然にも/usr、そのアイデアを書き出した既存のソフトウェアが非常に多く存在していたため、そのアイデアは決して現実のものにはなりませんでした。

私の個人的な好みはで/opt、製品ごとに個別のサブディレクトリがあります。これにより、製品の削除が単純なケースになり rm -frます。ただし、すべてのソフトウェアが適切なパッケージマネージャーを介してインストールされている場合は重要ではなく、インストールするソフトウェアがこれらの規則に厳密に従わず、構成などをどこかに書き込む/usr場合でも、どちらでも構いませんが、反対の理由で。

私はこの問題について少し異なる見解を持っています。jlliagreの答えは
すべて正しいですが、私にとって実用的なアプリケーションは、クラスターにソフトウェアをデプロイするとき、デフォルトの環境変数とデフォルトのライブラリの再利用になります。

単純に- /usr/localとそのすべての子ディレクトリは、などの適切なenv変数にPATHありMANPATH、/usr/local/lib{,64}ldconfigにあります（/etc/ld.so.conf.d/）。

/opt/OTOHはそうではありません。これは、システムに共存するために複数のバージョンまたは競合するパッケージを必要とする場合に有利ですが、何らかの環境管理（たとえば、環境モジュールまたはソフトウェアコレクション）を必要とし、潜在的に「無駄になる」という欠点がありますの各インストールは/opt完全に自己完結型であるため、共有ライブラリを複製することでストレージスペースを確保できます。

共有するという性質の/usr/localために、例えばバイナリは等ではなく直接インストールされます/usr/local/bin（そしてmanページは適切になります/usr/local/share/man/...）/usr/local/app/{bin,share/man,...}。