☰

Warum akzeptiert RPM mein freigegebenes Objekt nicht als Abhängigkeit?

tag-icon • tag-icon rhel dependencies packaging
Warum akzeptiert RPM mein freigegebenes Objekt nicht als Abhängigkeit?

Ich habe ein RPM-Paket mit erstellt rpmbuildund das Paket hat die folgenden Abhängigkeiten:

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

Ich versuche, es auf einem Rechner mit openSUSE zu erstellen. Allerdings erhalte ich den folgenden Abhängigkeitsfehler:

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

Meine Frage betrifft die Libssl-Abhängigkeit. In meinem System sind die folgenden gemeinsam genutzten Objekte vorhanden:

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

Meine Frage ist: Warum gibt RPM mir den Fehler aus, wenn ich es libssl.so.1.1installiert habe? Mein RPM-Paket hängt von ab libssl.so.1.0.0, sollte es also nicht kompatibel sein? Soweit ich weiß, definiert die erste Zahl die ABI-Kompatibilität zwischen den gemeinsam genutzten Objekten, 1.1sollte also mit 1.0Abhängigkeit gut funktionieren.

Wenn ich schließlich Folgendes ausführe:

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

Jetzt, da wir haben /usr/lib64/libssl.so.1.0.0, funktioniert es:

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

Antwort1

Meine Frage lautet: Warum zeigt RPM diesen Fehler an, wenn ich es libssl.so.1.1installiert habe?

Ihr RPM erfordert libssl.so.1.0.0, nicht libssl.so.1.1(siehe unten).

Mein RPM-Paket hängt von ab libssl.so.1.0.0. Sollte es also nicht kompatibel sein? Soweit ich weiß, definiert die erste Zahl die ABI-Kompatibilität zwischen den gemeinsam genutzten Objekten. Daher 1.1sollte es mit der Abhängigkeit gut funktionieren 1.0(korrigieren Sie mich bitte, wenn ich falsch liege).

Viele Projekte verwenden die Hauptnummer als Indikator für die Abwärtskompatibilität, aber das ist keine Voraussetzung. Was erforderlich ist, ist, dass verschiedene Versionen von Bibliotheken mit demselben Soname kompatibel sind. Aus diesem Grund werden RPM-Anforderungen als Sonames und Bibliothekssymbole ( , libc.so.6) ausgedrückt GLIBC_2.14: Der Soname gibt an, welche Bibliothek mit welchem ​​Soname erforderlich ist, und die Symbole geben an, welche Version der Bibliothek benötigt wird (oder höher). Die Garantie (von den Bibliotheksentwicklern) funktioniert folgendermaßen: Jedes mit einer bestimmten Version einer Bibliothek kompilierte Programm kann mit dieser oder einer späteren Version verwendet werden, solange der Soname gleich bleibt; und jedes mit einem bestimmten Satz versionierter Bibliothekssymbole kompilierte Programm kann mit jeder Version der Bibliothek mit demselben Soname verwendet werden, der auch alle diese versionierten Bibliothekssymbole bereitstellt.

libssl1.1 ist nicht abwärtskompatibel zu 1.0; tatsächlich ist die Migration ziemlich schwierig. Ein mit libssl1.0 kompiliertes Programm kann nicht mit 1.1 verwendet werden libssl. Um dies zu kennzeichnen, haben die Bibliotheken unterschiedliche Sonames.

verwandte Informationen