Filesystem Hierarchy Standard によると、/opt
は、「アドオンアプリケーションソフトウェアパッケージのインストール」用です。 /usr/local
は「ソフトウェアをローカルにインストールするときにシステム管理者が使用するため」です。これらの使用例はかなり似ています。ディストリビューションに含まれていないソフトウェアは、通常、デフォルトでどちらかにインストールするように構成されています/usr/local
または/opt
特定の韻や彼らが選んだ理由はありません。
私が見逃している違いはありますか、または両方とも同じことをしますが、歴史的な理由で存在しますか?
どちらもオペレーティングシステムに属していないファイルを含むように設計されていますが、_/opt
_と_/usr/local
_は同じファイルセットを含むことを意図していません。
_/usr/local
_は、通常make
コマンドを使用して管理者が作成したファイルをインストールする場所です(例:_./configure; make; make install
_)。アイデアは、オペレーティングシステムの一部であるファイルとの衝突を回避することです。これは、上書きされるか、ローカルのファイルを上書きします(たとえば、_/usr/bin/foo
_はOSの一部であり、_/usr/local/bin/foo
_はローカルの代替です) )。
_/usr
_の下のすべてのファイルはOSインスタンス間で共有できますが、これはLinuxではほとんど行われません。 _/usr
_は読み取り専用として定義されていますが、ソフトウェアのローカルインストールを成功させるには_/usr/local/bin
_を読み取り/書き込みにする必要があるため、これはFHSがわずかに自己矛盾している部分です。 FHSのインスピレーションの主な源であったSVR4ファイルシステム標準は、_/usr/local
_を避け、代わりに_/opt/local
_を使用してこの問題を解決することを推奨しています。
_/usr/local
_はオリジナルのBSDからの遺産です。当時、_/usr/bin
_ OSコマンドのソースコードは_/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ジャーナルは、この正確なトピックについてこのポイント/カウンターポイントディスカッション here を行いました。
私にとって、個人的には、@ philfrのリンクでビルが言ったことです:
開発システムまたはサンドボックスでは、/ optディレクトリを使用して、物事を投げて、それらが機能するかどうかを確認することができます。自分で物事をパッケージ化して試してみるつもりはありません。アプリが機能しない場合は、/ opt/mytestappディレクトリをrmするだけで、そのアプリケーションは履歴になります。大規模なデプロイを実行している場合はパッケージ化が理にかなっている場合があります(アプリをパッケージ化する場合があります)が、多くの場合、/ optにあるものをトスするのはいいことです。
残念ながら、ほとんどのmake install
スクリプトは、ファイルに/usr/local
にシンボリックリンクを作成する代わりに、そこにプッシュします:-/
まず、厳密な答えはないと思います。経歴によって、管理者が異なれば意見も異なります。歴史的には、/usr/local
が最初に登場しました。それはバークレー、IIRCの大会でした。 System Vの開発中のある時点で、私が間違っていなかった場合(これはずっと前のことであり、私はメモを取らなかった)、マウントすることができるかどうかの決定または要望がありました/usr
読み取り専用。つまり、新しいソフトウェアを追加できませんでした。それが/opt
が発明された理由かもしれません。たまたま、/usr
に書き込みを行った既存のソフトウェアが多すぎて、そのアイデアが実際に実現することはありませんでした。
私の個人的な好みは/opt
で、製品ごとに個別のサブディレクトリがあります。これにより、製品の削除がrm -fr
の単純なケースになります。ただし、すべてのソフトウェアが適切なパッケージマネージャーを介してインストールされている場合は問題ありません。インストールするソフトウェアがこれらの規則に厳密に従っていない場合、/usr
の下に構成などを書き込むと、どちらも重要ですが、反対の理由があります。
私はこの問題について少し異なる見方をしています。
jlliagre 's answer のすべてが正しい一方で、ソフトウェアをクラスタにデプロイするときの実用的なアプリケーションは、デフォルトの環境変数とデフォルトになりますライブラリの再利用。
単に-/usr/local
とその子ディレクトリすべてがPATH
やMANPATH
などの適切な環境変数にあり、/usr/local/lib{,64}
はldconfigの(/etc/ld.so.conf.d/
)。
/opt/
OTOHはそうではありません—これは、複数のバージョンまたは競合するパッケージをシステムに共存させる必要がある場合に有利ですが、何らかの環境管理が必要です(例: environment-modules または- ソフトウェアコレクション )。また、/opt
の各インストールは完全に自己完結型であるため、共有ライブラリを複製することによってストレージスペースを「浪費」する可能性があるという欠点があります。
/usr/local
の共有された性質が機能するためには、たとえばバイナリは、/usr/local/bin
などではなく、直接/usr/local/share/man/...
(およびマニュアルページを適切な/usr/local/app/{bin,share/man,...}
に)にインストールします。
2.2.6以降のFreeBSDと、バージョン9以降のRed Hat Linuxを公平に使用している...
/usr/local == Old School Conventions
/opt == New School Conventions
UNIX/Linuxファイルシステムでの配置は、絶対的なロジックよりも、慣例と伝統に関係しています。
それ以外の場合、私はほとんどすべての他の人に同意します。 :-)
ルールには常にいくつかの例外があります。 1日の終わりに、セットアップに最適なものを決定します(可能な場合)。