開発パッケージが.soパッケージを提供するのはなぜですか？

ディストリビューション内のソフトウェアは一貫した方法で機械的に接続されており、見つかると予想されるため、事前にビルドされたlibavcodec.so.54パッケージにはバージョンのない名前は必要ありません。

ただし、ソフトウェアを直接構築すると、同様のソフトウェアが頻繁に使用されますが、バージョンが管理されていないこと-lavcodecがわかります。libavcodec.so繰り返しますが、ビルドスクリプトではこれらの名前が存在すると予想できます。

リリースパッケージには、バージョン指定されていない名前は必要ないため、デフォルトでは含まれていませんが、他のソフトウェアをビルドするときに便利なため、-develパッケージに含まれています。他のディストリビューションは説明が異なり、.so基本パッケージにリンクが含まれています。どちらも合理的な選択です。

これを処理する方法はさまざまですが、一般的に自動化されたパッケージ管理を使用していない場合は処理する必要はありません。実際に最大自動化されたパッケージマネージャが実行することの1つは、自動化されたパッケージ管理によって引き起こされる問題を修正することです。これは、パッケージマネージャが価値がないという意味ではなく、実際に必要な余分な修正の追加価値が高価であるという意味にすぎません。

パッケージ管理アプローチを採用することを決めると、自分が閉じ込められます。 rootfsの制御を1つのモードまたは別のモードに渡し、その時点から問題を受け入れる必要があります。それ以来、あるファイルが別のファイルに依存していることを知る唯一の方法は、ネットワーク全体を開くことを解決することです。床が見えるまで。

パッケージマネージャは、ネットワークをダイナミックリンクライブラリスレッドの内部、スレッドの上に編みます。パッケージ管理ソリューションは、動的接続に大きく依存することがよくあります。アプリケーションセット全体が同じライブラリを取得できる場合、パッケージマネージャはバージョン管理をより簡単に実行できます。したがって、パッケージマネージャ間の最大の違いは、動的ライブラリのバージョン管理を処理するためのさまざまな戦略です。特に、次のような場合にさらにそうです。FHS環境は、ルートツリーが実際にパズルの唯一の他の主要な変数であるためです。あなたはapt以下に基づいてこれらの典型的なものの1つを指摘しました。概要S.