CR library version change on libgtop

[raines]

I tried to upgrade a workstation to the CR but got several failures on libgtop like this one:

Code: Select all

Error: Package: marco-1.8.2-2.el7.x86_64 (epel)
           Requires: libgtop-2.0.so.7()(64bit)
           Removing: libgtop2-2.28.4-6.el7.x86_64 (@anaconda)
               libgtop-2.0.so.7()(64bit)
           Updated By: libgtop2-2.28.4-7.el7.x86_64 (cr)
              ~libgtop-2.0.so.10()(64bit)

Why on such a minor update (according to the version numbers on the package) is the actual dynamic library version changing from 7 -> 10?

[gerald_clark]

Why do you have cr enabled?

[TrevorH]

If you want to use the CR repo then several packages from EPEL require the older libgtop and newer versions of those can be found in epel-testing. You'll need to --enablerepo=epel-testing for the duration of the update or, alternatively, you can remove the packages that cause the conflict and update without them and later reinstall them when EPEL have caught up. It's likely that it's a chicken and egg situation with EPEL waiting for CentOS 7.1 GA before those get promoted from -testing to the main EPEL.

[raines]

But I have a more general questions: shouldn't any change in the dynamic lib that causes backward incompatibility like this require a change in the major version of the library. Since the RPM package only goes from 2.28.4-6 to 2.28.4-7 that clearly is not the case. In fact the base gtop2 package is not even changing version. Only RedHat's sub-revision. So why is the dynamic library changing from .so.7 to .so.10?

[TrevorH]

No idea, you'd have to ask Redhat. I only know that EPEL must be aware of the change as the packages in -testing are set up to work with the update.

[chemal]

But I have a more general questions: shouldn't any change in the dynamic lib that causes backward incompatibility like this require a change in the major version of the library. Since the RPM package only goes from 2.28.4-6 to 2.28.4-7 that clearly is not the case. In fact the base gtop2 package is not even changing version. Only RedHat's sub-revision. So why is the dynamic library changing from .so.7 to .so.10?

As you say: Icompatible changes require a change in the major version of the library, that's why it goes from .so.7 to .so.10. This 7 was the old major version and this 10 is the new major version of the library. It has nothing to do with the version (2.28.4-6 or 2.28.4-7) of the software or the package. And as you can see from the changelog:

* Fri Mar 28 2014 David King <dking@redhat.com> - 2.28.4-7
- Allow up to 1024 CPUs (#1082123)

That's hardly more than a -6 to -7 jump.