0

I've built a rpm package using rpmbuild, and the package has the following dependencies:

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

I'm trying to build it in a machine running openSUSE. However, I'm getting the following dependency error:

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

My question is regarding the libssl dependency. I have the following shared objects existing in my system:

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

My question is: Why RPM is giving me the error if I have libssl.so.1.1 installed? My RPM package depends on libssl.so.1.0.0, so shouldn't it be compatible? As far as I know, the first number defines the ABI compatibility between the shared objects, so 1.1 should work fine with 1.0 dependency .

Finally, if I run:

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

Now, having /usr/lib64/libssl.so.1.0.0, it works:

51f32ecb00b7:/rpm # rpm -U pkg.rpm 
error: Failed dependencies:
    libjson-c.so.2()(64bit) is needed by pkg.noarch
3
  • Having files on your computer != having the files according to the RPM database. Did you build the RPM on an OpenSUSE box? Add to the end of your find command listing them on your machine to | xargs -n1 rpm -q --whatprovides and I'd bet that some or all aren't in the DB. – Aaron D. Marasco Jan 22 '19 at 21:45
  • @AaronD.Marasco I'm using an OpenSUSE docker image. Even though the libssl.so.1.1 already came with the image that I'm using, it seems that it is inside the RPM DB: rpm -q --whatprovides /usr/lib64/libssl.so.1.1 gives me libopenssl1_1-1.1.0i-lp150.3.15.1.x86_64, which is, in fact, installed – felipeek Jan 22 '19 at 22:01
  • And yes, the RPM was built using the same OpenSUSE docker image – felipeek Jan 22 '19 at 22:08
2

My question is: Why RPM is giving me the error if I have libssl.so.1.1 installed?

Your RPM requires libssl.so.1.0.0, not libssl.so.1.1 (see below).

My RPM package depends on libssl.so.1.0.0, so shouldn't it be compatible? As far as I know, the first number defines the ABI compatibility between the shared objects, so 1.1 should work fine with 1.0 dependency (please correct me if I'm wrong).

Many projects use the major number as a backward-compatibility indicator, but it’s not a requirement. What is required is that different versions of libraries with the same soname be compatible. That’s why RPM requirements are expressed as sonames and library symbols (libc.so.6, GLIBC_2.14): the soname indicates which library is required, with which soname, and the symbols indicate which version of the library is needed (or later). The guarantee (from the library developers) works thus: any program compiled with a given version of a library can be used with that version or any later one, as long as the soname stays the same; and any program compiled with against a given set of versioned library symbols can be used with any version of the library, with the same soname, which also provides all those versioned library symbols.

libssl 1.1 isn’t backwards compatible with 1.0; in fact the migration is rather difficult. A program compiled against libssl 1.0 can’t be used with libssl 1.1. To mark this fact, the libraries have different sonames.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.