オペレーティングシステムごとにOS Xにパッケージの依存関係をインストールする標準的な方法が異なるため、すべてのライブラリの依存関係がこのAppフォルダにコピーされます。
Windowsアプリケーション開発者には2つのオプションがあります。ライブラリをサブパッケージとしてインストールできます。たとえば、ゲームインストーラはdirectXライブラリをインストールします。ただし、通常、ユーザーはシステムへの依存関係をコピーするか共有するかを選択するオプションはありません。
Linuxでは、パッケージマネージャ（たとえばapt-get）が依存関係を繰り返し解決し、システム全体にインストールします。もちろん、アプリケーションはまだ同じソースライブラリの異なるバージョンを使用できるため、冗長な依存関係の問題は必ずしも解決されるわけではありません。
たとえば、一部のアプリケーションではこれを必要としますが、くそ、libboost-filesystem1.42libboost-filesystem-1.49を使用できますが、パッケージパーサーがすでにlibboost-filesystem-1.49を持っているかどうかを判断できないため、役に立ちません。
一方、すでに異なるバージョンがあるため、システム全体のパスに古いライブラリをインストールしたくありません。
質問：App特定のアプリケーションの依存関係をアプリケーション固有のフォルダ（Mac OS Xのフォルダなど）にインストールできるようにする標準のパッケージマネージャオプションはありますか？
答え1
あなたは間違っています。 「古い」ライブラリは、目的の動作であるシステムのフルパスにインストールされます。仕組みは次のとおりです。 2つのライブラリバージョンがバイナリレベルで互換性がある場合は、1つだけインストールすると、そのバージョンを使用するすべてのアプリケーションは同じライブラリファイルを使用します。両方のライブラリバージョンがバイナリレベルで互換性がない場合は、それぞれ一意の名前を持つ複数のコピーをインストールし、異なるバージョンのライブラリを必要とするアプリケーションは適切なライブラリファイルを使用します。
たとえば、libboost-filesystem-1.49（に/usr/lib/libboost_filesystem.so.1.49.0）インストールした場合、バイナリは互換性がないため、バージョン1.42.0が必要なアプリケーションには役立ちません。アプリケーションにはが必要です/usr/lib/libboost_filesystem.so.1.42.0。アプリケーションをインストールすると、パッケージマネージャは必要なバージョンのライブラリを自動的にインストールします。 1.42を必要とするアプリケーションと1.49を必要とするアプリケーションがある場合は、2つの異なるバージョンのライブラリがあり、/usr/libそれぞれ独自のファイル名を使用して平和に共存できます。最近、ほとんどのパッケージマネージャは、アプリケーションで使用されなくなったライブラリのバージョンを自動的に削除することもできます。
アプリケーションディレクトリにライブラリをインストールすることは、良いパッケージ管理と配布チャネルを持たないオペレーティングシステムの依存関係を処理する貧しい人々の方法です。タスクをシームレスに実行するために、アプリケーションに必要なすべてのライブラリをアプリケーション自体と一緒にまとめます。つまり、同じライブラリバージョンの複数のコピーがあり、ライブラリをアップグレードする簡単な方法はありません。結局、同じライブラリの古いコピーが複数あります。
パッケージマネージャがあるということは、そうする必要がないことを意味するので、アプリケーションディレクトリにライブラリをインストールするオプションがあり、将来もないでしょう。