私は最近、Debianベースのディストリビューションには、パッケージマネージャを介してインストールされたすべてのアプリケーションが使用する必要がある固定された共通の依存関係とライブラリのセットがあることがわかりました。
Windowsと比較して、各アプリケーションは通常独自の依存関係を提供するため、Windows OSのインストールは同じ依存関係/ライブラリの複数のインスタンスをインストールし、各アプリケーションは依存関係自体の更新を管理する必要があります。
一部の開発者はAPTパッケージマネージャと互換性のあるソフトウェアを作成することを知っていますが、「Windows」の方法でソフトウェアを作成するアプリケーション開発者も多いと思います。
したがって、私の質問は、アップストリーム開発者がバンドル依存関係を含む大規模なモノリシックインストールを展開することを意図したソフトウェアを作成した場合、ソフトウェアがローカル依存関係の代わりに共通の依存関係コレクションを使用するようにAPTパッケージマネージャがソースコードを書き換える必要があるかどうかということです。です。 ？
もしそうなら、これは頻繁に起こりますか？これがパッケージマネージャの主な任務ですか？
答え1
したがって、私の質問は、アップストリーム開発者がバンドル依存関係を含む大規模なモノリシックインストールを展開することを意図したソフトウェアを作成した場合、ソフトウェアがローカル依存関係の代わりに共通の依存関係コレクションを使用するようにAPTパッケージマネージャがソースコードを書き換える必要があるかどうかということです。です。 ？
インストール全体がそうでない限り、必ずしもそうではありません。紛争既存のライブラリまたはファイル名を使用してください。つまり、システムにすでに1つ/lib/foobar（バージョン12）があり、モノリシックパッケージにfoobarv.9が必要でバンドルされている場合、モノリシックパッケージはそのパス名がすでに使用されているため、foobarファイル名を使用してv.9保存できません。/lib/foobarできる/lib/foobar_v9、またはおそらくを使用してください.../monolithic_app_dir/lib/foobar。
もしそうなら、これは頻繁に起こりますか？これがパッケージマネージャの主な任務ですか？
はい、必要に応じて予防してください整えるさまざまなレベルの依存関係地獄は、パッケージ管理者が主に実行する作業です。
答え2
Debian ポリシーDebian パッケージを作成するときは、プログラムにバンドルされているライブラリ、ツールなどをパッケージから分離する必要があります。また、Debian ポリシーでは、ライブラリを少なくともランタイムパッケージ（例libfoo-version：）と、静的ライブラリとヘッダファイルを含む開発バージョン（例libfoo-version-dev：）に分割する必要があります。
自分のシステムで行うことは自分のビジネスですが、モノリシックアプリケーションをパッケージ化するDebian開発者（DD）はバンドルを解放する必要があります。これは、Debianの既存のライブラリに依存するか、そのためのパッケージを作成することを意味します（まだ存在しない場合）。
他のディストリビューションには異なるポリシーがある可能性がありますが、ほとんどの場合、公式リポジトリのパッケージをバンドル解除する必要があります。これは、パッケージングのポイントを崩し、特定のライブラリを使用するすべてのプログラムにライブラリセキュリティ更新プログラムを適用するのを面倒にするからです。