☰

RPM が共有オブジェクトを依存関係として受け入れないのはなぜですか?

tag-icon • tag-icon rhel dependencies packaging
RPM が共有オブジェクトを依存関係として受け入れないのはなぜですか?

を使用して rpm パッケージをビルドしましたrpmbuildが、パッケージには次の依存関係があります。

51f32ecb00b7:/rpm # rpm -qpR pkg.rpm 
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.17)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.5)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libcrypto.so.1.0.0()(64bit)
libcurl.so.4()(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libjson-c.so.2()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
libssl.so.1.0.0()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

openSUSE を実行しているマシンでビルドしようとしています。ただし、次の依存関係エラーが発生します。

51f32ecb00b7:/rpm # rpm -U pkg.rpm 
error: Failed dependencies:
    libcrypto.so.1.0.0()(64bit) is needed by pkg.noarch
    libjson-c.so.2()(64bit) is needed by pkg.noarch
    libssl.so.1.0.0()(64bit) is needed by pkg.noarch

私の質問は、libssl の依存関係に関するものです。私のシステムには、次の共有オブジェクトが存在します。

51f32ecb00b7:/rpm # find / | grep libssl*.so
/lib64/libss.so.2
/lib64/libss.so.2.0
/usr/lib64/libss.so.2
/usr/lib64/libss.so.2.0
/usr/lib64/libssl.so.1.1

私の質問は、 をインストールしているのに、なぜ RPM がエラーを出すのかということですlibssl.so.1.1。私の RPM パッケージは に依存しているのでlibssl.so.1.0.0、互換性があるはずではないでしょうか。私の知る限り、最初の数字は共有オブジェクト間の ABI 互換性を定義するので、依存関係1.1で問題なく動作するはずです1.0。

最後に、以下を実行します。

51f32ecb00b7:/rpm # zypper install libopenssl1_0_0 
51f32ecb00b7:/rpm # find / | grep libssl*.so
/lib64/libss.so.2
/lib64/libss.so.2.0
/usr/lib64/libss.so.2
/usr/lib64/libss.so.2.0
/usr/lib64/libssl.so.1.1
/usr/lib64/libssl.so.1.0.0

さて、 があれば/usr/lib64/libssl.so.1.0.0、次のように動作します:

51f32ecb00b7:/rpm # rpm -U pkg.rpm 
error: Failed dependencies:
    libjson-c.so.2()(64bit) is needed by pkg.noarch

答え1

私の質問は、RPM をインストールしたのになぜエラーが発生するのかということですlibssl.so.1.1。

RPM には が必要ですlibssl.so.1.0.0。 ではありませんlibssl.so.1.1(下記参照)。

私の RPM パッケージは に依存しているのでlibssl.so.1.0.0、互換性があるはずではないでしょうか? 私の知る限り、最初の数字は共有オブジェクト間の ABI 互換性を定義するので、依存関係1.1があっても問題なく動作するはずです1.0(間違っていたら訂正してください)。

多くのプロジェクトでは、メジャー番号を下位互換性の指標として使用していますが、これは必須ではありません。必要なのは、同じ soname を持つ異なるバージョンのライブラリに互換性があることです。RPM の要件が soname とライブラリ シンボル ( libc.so.6、GLIBC_2.14) として表現されるのはそのためです。soname はどのライブラリがどの soname で必要かを示し、シンボルはどのバージョンのライブラリ (またはそれ以降) が必要かを示します。(ライブラリ開発者からの) 保証は次のように機能します。特定のバージョンのライブラリでコンパイルされたプログラムは、soname が同じである限り、そのバージョンまたはそれ以降のどのバージョンでも使用できます。また、特定のバージョン管理されたライブラリ シンボル セットに対して でコンパイルされたプログラムは、同じ soname を持つ任意のバージョンのライブラリで使用でき、これにより、それらのバージョン管理されたライブラリ シンボルもすべて提供されます。

libssl1.1 は 1.0 と下位互換性がありません。実際、移行はかなり困難です。1.0 用にコンパイルされたプログラムは1.1libsslでは使用できませんlibssl。この事実を示すために、ライブラリには異なる soname があります。

関連情報