複数のバージョンの共有ライブラリをインストールできないのはなぜですか？

実際に正しく実行されたら、複数のバージョンの共有ライブラリをインストールできます。

共有ライブラリの名前は通常次のとおりです。

lib<name>.so.<api-version>.<minor>

次に、次のライブラリへのシンボリックリンクがあります。

lib<name>.so
lib<name>.so.<api-version>

開発者がバイナリを生成するためにライブラリに接続すると、.soリンカはそのファイル名で終わるファイル名を探します。特定の状況で一度に1つしかインストールできないことは事実ですが、<name>これは開発者が同時に複数のバージョンのライブラリをターゲットにすることはできません。パッケージ管理者にとって、このシンボリックリンクは開発者だけがインストールする必要がある.so別のパッケージの一部です。-dev

リンカは、名前が終わるファイルを見つけて使用する.soと、そのライブラリ内の次のフィールドを探します。ソナム。 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>新しいバージョンは選択されません。

パッケージマネージャは通常、同じリリースに同じライブラリの複数のバージョンをパッケージ化しません。ディストリビューション全体（ライブラリを使用するすべてのバイナリを含む）は、通常、リリース前に各ライブラリの一貫したバージョンを使用するようにコンパイルされるためです。解放されました。すべてが一貫しており、リリース内のすべてが他のすべてと互換性があることを確認することは、出版社のワークロードの大部分を占めます。

ただし、ディストリビューションのあるバージョンから別のバージョンにシステムをアップグレードしても、以前のバージョンのライブラリが必要な古いパッケージがいくつかある場合は、複数のバージョンのライブラリが簡単に発生する可能性があります。例:

• libmysqlクライアント16以前のDebianにはincludelibmysqlclient.so.16.0.0とSymlinkが含まれていましたlibmysqlclient.so.16。
• libmysqlクライアント18現在の Debian から includelibmysqlclient.so.18.0.0と Symlink が含まれますlibmysqlclient.so.18。

この機能は許可されていません。ほとんどのライブラリ番号がどのように機能するのか、パッケージ名の変更による不便さのため、あまり一般的ではありません。

ドットで区切られたバージョン番号付けスキームXYZを使用している場合、バグが修正されると「マイクロ」バージョンZが頻繁に変更され、バグが修正されると「マイナー」バージョン番号Yが変更されます。旧バージョンと互換性がある変更され、「主な」バージョン番号Xは、APIの変更に応じて（時には主要なアドインに従って）変更する必要があります。

最新のバグを修正しない理由はなく、以前のバージョンと互換性のある変更によってソフトウェアが破損してはいけません。

ライブラリがこのように開発されたら、常にXYZをX.（Y + m）。（Z + n）に置き換えることができるはずです。与えられたmとnについて。つまり、同じ主要デジタルシリーズの最新バージョンにライブラリを常に交換できる必要があります。ライブラリ開発者が注意を払い、次のキー番号と互換性がある場合（たとえば、廃止されたアイテムを宣言したがまだ削除していない場合）、次のキー番号を使用することもできます。

パッケージ開発者の場合、これは数値ではなく名前のみを使用し、パッケージを更新して最新バージョンを提供できることを意味します。ライブラリをパッケージ化すると、abc2独自のソフトウェアを移動するのに多くの問題が発生します。頼るabc2使用するためにアップグレードするには、abc3移行パッケージが必要な場合があります。ほとんどの依存パッケージに適用できる場合は、ライブラリからメジャーバージョン番号を省略する方が便利です。したがって、ディストリビューションの特定の時点で両方が利用可能でabc2ある必要がありますが、しばしば呼び出され（まだ呼び出されていない）、ディストリビューションにパッケージの依存関係がない場合は、完全に削除できます。abc3abc3abcabc2abc3abc2abc2

番号付けスキームは一様に従わないが、インターネットの出現でこれらのスキームの使用方法に関する情報が広がり、図書館ユーザー（配布開発者を含む）が以前のバージョンのような重要な事項を明確にせず、何もしないように圧力を受けることになると想像できます。互換性。ライブラリに含まれているCHANGESファイルを読む必要がある場合、この状況はより一般的になります。

ライブラリではない反例はPython intpreterです。これは、マイナーな数値変更では、共有オブジェクトやピクリング形式と互換性がありません。そのため、Python（2.7シリーズの最新バージョン）とpython3（現在のpython3.4シリーズの最新バージョン）用のパッケージ、およびPython 2.6（ますます一般化）とPython 3.3用の明示的なパッケージが表示されます。