Bug in Rocky's systemtap-runtime-4.4-11 package?

Rocky Linux General
1

Hi,

this is my very first post here, so please direct me to a somewhere else if this is the wrong place to ask.

I did run a (mostly) successful CentOS 8.4 to Rocky 8.4 conversion by using the migrate2rocky.sh script with some minor unrelated tweaks. However, some additional packages were installed in the migration process to resolve recursive dependencies that were not necessary in CentOS 8.4.

I’ve looked into this and one of the reasons seems to be that the package systemtap-runtime-4.4-11.el8_4.x86_64 has different library version dependencies in CentOS 8.4 and Rocky 8.4.

This is an excerpt from ‘yum deplist systemtap-runtime-4.4-11.el8_4.x86_64’ command on CentOS 8.4:

  [...]
  dependency: libdyninstAPI.so.10.2()(64bit)
   provider: dyninst-10.2.1-2.el8.x86_64
   provider: gcc-toolset-10-dyninst-10.2.1-2.el8.x86_64
  [...]
  dependency: libsymtabAPI.so.10.2()(64bit)
   provider: dyninst-10.2.1-2.el8.x86_64
   provider: gcc-toolset-10-dyninst-10.2.1-2.el8.x86_64
 [...]

And this is an excerpt from the very same command in Rocky 8.4:

[...]
  dependency: libdyninstAPI.so.10.1()(64bit)
   provider: gcc-toolset-9-dyninst-10.1.0-1.el8.x86_64
[...]
 dependency: libsymtabAPI.so.10.1()(64bit)
   provider: gcc-toolset-9-dyninst-10.1.0-1.el8.x86_64
[...]

Also note that in CentOS 8.4 there are two providers of libdyninstAPI.so.10.2: dyninst-10.2.1-2.el8.x86_64 and gcc-toolset-10-dyninst-10.2.1-2.el8.x86_64, with the former being installed in my original CentOS 8.4 system. Whereas, in Rocky 8.4, there is only one provider of library version libsymtabAPI.so.10.1, which is gcc-toolset-9-dyninst-10.1.0-1.el8.x86_64.

So I finally ended up with gcc-toolset-9-dyninst-10.1.0-1.el8.x86_64 being installed in Rocky 8.4 together with all it’s recursive dependencies including the environment-modules-4.5.2-1.el8.x86_64 package, which messed up with the Lmod installation (from EPEL) from the original CentOS 8.4 .

I actually expected the packages in CentOS 8.4 and Rocky 8.4 to be binary compatible, also with respect to the library versions they depend on. Is this a wrong expectation or is this a bug in Rocky’s current systemtap-runtime-4.4-11 package?

Best regards
Jürgen

2

Both of those packages do provide the libdyninstAPI.so.10.2, but the gcc-toolset has it under /opt/rh/gcc-toolset-10/root.
Each gcc-toolset actually has their own systemtap.
The systemtap-runtime should use (and can see only) the libraries provided by dyninst (unless you scl enable the toolset).

Since toolsets use scl (Software Collections tool) and scl now can call module, you get the environment-modules …

Furthermore, systemtap-runtime should not see the toolset’s libdyninstAPI.so.10.1 (unless you scl enable…)

Yes, if systemtap-runtime-4.4-11 depends on libdyninstAPI.so.10.1()(64bit) and not libdyninstAPI.so.10.2()(64bit), then that package’s spec has an error.

3

Hi,

thanks for your response.

Well, scl was definitely not enabled in the original CentOS 8.4 system. The scl-utils package was not even installed in there, but has been installed automatically as a dependency of gcc-toolset-9-runtime.x86_64 during the migration process to Rocky 8.4 (together with environment-modules which is required by scl-utils). I do assume this has happened because the gcc-toolset-9-runtime package is the only provider of libdyninstAPI.so.10.1 on which the systemtap-runtime-4.4-11 depends in Rocky 8.4. I have now also checked the rpm package files systemtap-runtime-4.4-11.el8_4.x86_64.rpm from the CentOS and Alma repos and both of them require library version libdyninstAPI.so.10.2 rather than libdyninstAPI.so.10.1. So I also assume this is a bug in the Rocky rpm package. I am going to file a bug report in the Rocky bugzilla …

Best regards
Jürgen

4

This isn’t a bug of the spec file or the RPM itself. It is a bug in which the order of packages were built to begin with. If packages are not built in a correct order, old libraries are likely to be picked up as a result. This is one of those rare cases where systemtap was built/updated before dyninst. With that being said, the mirrors should have the fixes soon. Apologies for the mess.

5

Hi,

thank you for the very quick fix.

May I add a follow-up question:

Is the output of rpm -qpR package.rpm always supposed to be exactly the same for one and the same package file from Rocky 8.4 and CentOS 8.4? Or are there differences to be expected without being an indication of broken binary compatibility.

I did some spot checks with rpm files from the CentOS 8 and Rocky 8 repos and noticed differences for some of them.

Best regard
Jürgen

6

We build off RHEL 8 sources, so I’m not sure I understand your question. You will need to provide more information.

7

Hi,

ok. I don’t think of explicit package dependencies in the spec files but of
automatic library dependencies that are added when a binary package is built
and may depend on the build environment.

For example, the perf-4.18.0-305.17.1.el8_4.x86_64.rpm from CentOS 8 does have
an automatic dependency from

libdebuginfod.so.1()(64bit
libdebuginfod.so.1(ELFUTILS_0.178)(64bit)

while the very same rpm file from Rocky 8 does not. So in CentOS 8.4 the perf
binary links against libdebuginfod.so.1 (for whatever reasons) while in
Rocky 8.4 it does not:

centos84> ldd /usr/bin/perf | grep libdebug
        libdebuginfod.so.1 => /lib64/libdebuginfod.so.1 (0x00007ffb98ff6000)
centos84>

rocky84> ldd /usr/bin/perf | grep libdebug
rocky84>

Another example would be the lftp-4.8.4-2.el8.x86_64.rpm package. The Rocky 8.4
package depends on

libidn2.so.0()(64bit)
libidn2.so.0(IDN2_0.0.0)(64bit)

while the very same CentOS 8.4 package file does not.

A third example would be gnome-color-manager-3.28.0-3.el8.x86_64.rpm (among
some others) which depends on libexiv2.so.27 in Rocky 8.4 but on
libexiv2.so.26 in the CentOS 8.4 rpm packages.

I also noticed quite a number of rpm packages that depend on librt.so.1
in CentOS 8.4 but not so in the Rocky 8.4 packages.

Does that count as breakage of binary compatibility?

Best regards
Jürgen

8

BTW: I currently don’t have access to the binary RPMs from RHEL 8.4, so I have to resort
to the CentOS 8.4 packages as reference.

9

We do not count to breaking of binary compatibility unless it inherently breaks the expected usage of said binaries or libraries. This typically comes down to the order in which the packages were built. In the case of perf, that comes from the kernel builds, so I cannot comment on why that link is not there. As for librt.so.1 this likely occurred as a direct result of us not having i686 packages when we initially started building Rocky, and it also likely happened because of us using the newer file package which breaks a lot of the dep solving. The only packages that do not ask for librt.so.1 right now is:

fuse3-libs
gnome-desktop3
pacemaker-cluster-libs
pacemaker-libs

Those four we can rebuild to verify if librt.so.1 comes back by using an older version of file but I cannot guarantee this.