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?