多くの場合、特定のプログラムがライブラリバージョンxyとxzに依存するプログラムがありますが、私が知る限り、xyとxzの両方をインストールできるパッケージマネージャーはありません。 qt4とqt5は同時にインストールできます）が、（おそらく）マイナーバージョンではありません。
どうしてこれなの？のように、それを妨げる制限要因は何ですか？この一見便利な機能を許可しないことには、十分な理由があるはずだと思います。たとえば、共有オブジェクトをロードするときにロードするバージョンを示すフィールドがないため、Linuxがロードするものを決定する方法を知る方法はありませんか？それとも理由は本当にないのですか？とにかく、すべてのマイナーバージョンは互換性があると思われますか？
回答:
実際、正しく実行されていれば、複数のバージョンの共有ライブラリをインストールできます。
共有ライブラリは通常、次のように命名されます。
lib<name>.so.<api-version>.<minor>
次に、以下の名前でライブラリへのシンボリックリンクがあります。
lib<name>.so
lib<name>.so.<api-version>
開発者がライブラリをリンクしてバイナリを生成する場合.so、リンカが検出するのはファイル名です。実際、一度にインストールできるのは1つ<name>だけですが、これは、開発者が複数の異なるバージョンのライブラリを同時に対象にできないことを意味します。パッケージマネージャーでは、この.soシンボリックリンクは、-dev開発者のみがインストールする必要がある別のパッケージの一部です。
リンカが末尾が名前のファイルを見つけて.so使用すると、そのライブラリ内でsonameというフィールドを探します。sonameは、生成されるバイナリに埋め込むファイル名をリンカーに通知し、実行時にどのファイル名を探すかを通知します。sonameはに設定されることになっていますlib<name>.so.<api-version>。
したがって、実行時に、動的リンカーはそれを探しlib<name>.so.<api-version>て使用します。
意図は次のとおりです。
<minor>アップグレードによってライブラリのAPIが変更されることはなく、<minor>がより高いバージョンに変更された場合、すべてのバイナリを新しいバージョンにアップグレードしても安全です。バイナリはすべてlib<name>.so.<api-version>、最新のへのシンボリックリンクであるという名前でライブラリを探してlib<name>.so.<api-version>.<minor>いるため、アップグレードされます。<api-version>アップグレードによってライブラリのAPIが変更されるため、既存のバイナリアプリケーションに新しいバージョンを使用させるのは安全ではありません。<api-version>が変更された場合、これらのアプリケーションは名前を探しているlib<name>.so.<api-version>が、の値が異なるため<api-version>、新しいバージョンは取得されません。ライブラリを使用するすべてのバイナリを含むディストリビューション全体は通常、配布前にすべてのライブラリの一貫したバージョンを使用するようにコンパイルされるため、パッケージマネージャーは同じ配布バージョン内の同じライブラリの複数のバージョンをパッケージ化しないことがよくあります。リリースされました。すべてに一貫性があり、ディストリビューションのすべてが他のすべてと互換性があることを確認することは、ディストリビューターのワークロードの大きな部分です。
ただし、システムをディストリビューションのあるバージョンから別のバージョンにアップグレードしても、古いライブラリバージョンを必要とする古いパッケージがいくつかある場合は、簡単にライブラリの複数のバージョンになる可能性があります。例：
libmysqlclient.so.16.0.0、symlink が含まれていますlibmysqlclient.so.16。libmysqlclient.so.18.0.0、symlink が含まれていますlibmysqlclient.so.18。この機能は禁止されていません。ほとんどのライブラリの番号付けが機能する方法と、パッケージ名の変更の不便さのために、あまり一般的ではありません。
ドット付きバージョン番号スキームXYZを使用する場合XYZ「マイクロ」バージョンZはバグ修正で頻繁に変更され、「マイナー」番号Yは下位互換性の変更で変更され、「メジャー」バージョン番号XはAPI変更で変更する必要があります（場合によっては主要な追加機能）。
最新のバグを修正したくない理由は決してないはずです。また、下位互換性のある変更によってソフトウェアが壊れることもないはずです。
ライブラリがそのように開発されている場合、常にXYZをX.（Y + m）。（Z + n）で置き換えることができるはずです。任意の与えられたmとnに対して。つまり、ライブラリを常に同じメジャー番号シリーズの最新のものに置き換えることができるはずです。ライブラリ開発者が注意深く、次のメジャー番号に互換性がある場合（たとえば、廃止予定であるが、まだ削除していないなど）、次のメジャー番号を使用することもできます。
パッケージ開発者にとって、これは、名前を1つだけ、または番号なしの名前で使用して、パッケージを更新するだけで最新バージョンを提供できることを意味します。ライブラリをパッケージで出荷する場合は、abc2フープを通過して、アップグレードに依存する独自のソフトウェアを移行abc2する必要abc3があります。移行パッケージを使用する場合もあります。依存しているほとんどのパッケージで機能する場合は、ライブラリからメジャーバージョン番号を除外する方が便利です。したがって、ディストリビューションで両方のabc2とabc3がいつか利用可能である必要がある場合でも、（まだ存在しないときに呼び出されたように）呼び出されるabc3ことが多く、ディストリビューション内で依存するパッケージがなくなるとすぐにドロップすることが可能になりますabcabc2abc3abc2abc2 完全に。
番号付けスキームは一律ではありませんが、そのようなスキームの使用方法に関する情報をインターネットで広めることと、ライブラリーユーザー（ディストリビューション開発者を含む）から後方互換性などの重要なことを明確にせずに圧力をかけるようになったことでしか想像できません。ライブラリに含まれているCHANGESファイルを読まなければならないことは、これがより一般的になっていることに貢献しています。
ライブラリではない反例の1つにpython intpreterがあります。これは、共有オブジェクトとマイナー番号の変更での酸洗い形式に互換性がありません。したがって、python（2.7シリーズの最新）、python3（現在のpython3.4シリーズの最新）、およびpython 2.6（あまり一般的ではない）の明示的なパッケージとpython 3.3のパッケージが表示されます。