最近、Debian ベースのディストリビューションには基本的に、パッケージ マネージャーを通じてインストールされるすべてのアプリケーションで使用する必要がある共通の依存関係とライブラリの固定コレクションがあることを知りました。
これを、たとえば Windows と比較してみましょう。Windows では、通常、各アプリケーションが独自の依存関係を提供するため、Windows OS のインストールでは、同じ依存関係/ライブラリのインスタンスが何度もインストールされ、各アプリケーションがこれらの依存関係の更新を独自に管理する必要があります。
一部の開発者が APT パッケージ マネージャーと互換性のあるソフトウェアを開発していることは知っていますが、開発者が「Windows」方式でソフトウェアを作成したアプリケーションも多数あるはずです。
そこで私の質問は、アップストリーム開発者が、バンドルされた依存関係を備えた大規模なモノリシックインストールを配布する意図でソフトウェアを作成した場合、APT パッケージのメンテナーは、ソフトウェアがローカル依存関係ではなく依存関係の共同コレクションを使用するようにソースを書き直す必要があるかどうかです。
もしそうなら、これは頻繁に発生し、パッケージメンテナーにとって大きなタスクになりますか?
答え1
そこで私の質問は、アップストリーム開発者が、バンドルされた依存関係を備えた大規模なモノリシックインストールを配布する意図でソフトウェアを作成した場合、APT パッケージのメンテナーは、ソフトウェアがローカル依存関係ではなく依存関係の共同コレクションを使用するようにソースを書き直す必要があるかどうかです。
必ずしもそうではありません。モノリシックインストールが対立既存のライブラリまたはファイル名で保存することはできません。つまり、システムにすでに/lib/foobar（バージョン12）があり、モノリシックパッケージがバージョン9を必要としてバンドルしている場合、そのモノリシックパッケージはファイル名を使用してバージョン9foobarを保存することはできません。なぜなら、そのパス名は取得されているためです。foobar/lib/foobarできた/lib/foobar_v9を使用するか、あるいは を使用します.../monolithic_app_dir/lib/foobar。
もしそうなら、これは頻繁に発生し、パッケージメンテナーにとって大きなタスクになりますか?
はい、予防し、必要に応じて並べ替えるさまざまなレベルの依存関係地獄は、パッケージメンテナーが行うことのほとんどです。
答え2
Debianポリシープログラムにバンドルされているライブラリやツールなどは、Debian パッケージを作成するときにプログラムから切り離す必要があるということです。Debian ポリシーでは、ライブラリを少なくともランタイム パッケージ (例libfoo-version) と、静的ライブラリとヘッダーを含む開発バージョン (例libfoo-version-dev) に分割することも要求しています。
自分のシステムで何を行うかは個人の自由ですが、モノリシック アプリケーションをパッケージ化する Debian 開発者 (DD) は、アンバンドルすることが求められます。つまり、Debian の既存のライブラリに依存するか、まだ存在しない場合はそれらのパッケージを作成する必要があります。
他のディストリビューションではポリシーが異なる場合がありますが、ほとんどのディストリビューションでは公式リポジトリ内のパッケージをアンバンドルする必要があります。これは、バンドルするとパッケージ化の目的が損なわれ、たとえば、特定のライブラリを使用するすべてのプログラムにライブラリのセキュリティ更新を適用することが難しくなるためです。