Yum / rpm throwing conflict errors for software not installed

[sawozny]

What would cause a yum repository of RPM installers to raise conflicts regarding or try to install for the purposes of obsoleting packages that are not installed?

The situation I’m facing is this. Percona is a company that offers MySQL and Galera pre-integrated (and to hear them tell it, optimized) and they have a repository that can be installed with a: sudo yum install https://repo.percona.com/yum/percona-re ... noarch.rpm

If you were to do a simple sudo yum update right after installing this repo and CentOS 7.7, you get a ton of conflicts and obsoleting related to packages in this repo that aren’t installed on the system. Here’s what I get:

Resolving Dependencies
--> Running transaction check
… bunch of updates I was expecting, then...
---> Package Percona-Server-shared-55.x86_64 0:5.5.62-rel38.14.el7 will be obsoleting
---> Package Percona-Server-shared-56.x86_64 0:5.6.47-rel87.0.1.el7 will be obsoleting
---> Package Percona-Server-shared-compat-57.x86_64 0:5.7.29-32.1.el7 will be obsoleting
---> Package Percona-XtraDB-Cluster-shared-55.x86_64 1:5.5.41-25.12.855.el7 will be obsoleting
---> Package Percona-XtraDB-Cluster-shared-56.x86_64 1:5.6.46-28.38.1.el7 will be obsoleting
---> Package Percona-XtraDB-Cluster-shared-57.x86_64 0:5.7.28-31.41.1.el7 will be obsoleting
---> Package Percona-XtraDB-Cluster-shared-compat-57.x86_64 0:5.7.28-31.41.1.el7 will be obsoleting
… bunch more updates I was expecting, then...
--> Processing Conflict: Percona-XtraDB-Cluster-shared-57-5.7.28-31.41.1.el7.x86_64 conflicts Percona-Server-shared-56
--> Processing Conflict: 1:Percona-XtraDB-Cluster-shared-56-5.6.46-28.38.1.el7.x86_64 conflicts Percona-Server-shared-56
--> Processing Conflict: 1:Percona-XtraDB-Cluster-shared-55-5.5.41-25.12.855.el7.x86_64 conflicts Percona-XtraDB-Cluster-shared-56
--> Processing Conflict: 1:Percona-XtraDB-Cluster-shared-55-5.5.41-25.12.855.el7.x86_64 conflicts Percona-Server-shared-55
--> Processing Conflict: Percona-Server-shared-compat-57-5.7.29-32.1.el7.x86_64 conflicts Percona-Server-shared-56
--> Processing Conflict: Percona-Server-shared-compat-57-5.7.29-32.1.el7.x86_64 conflicts Percona-Server-shared-55
--> Processing Conflict: Percona-Server-shared-55-5.5.62-rel38.14.el7.x86_64 conflicts Percona-Server-shared-56
--> Processing Conflict: Percona-XtraDB-Cluster-shared-compat-57-5.7.28-31.41.1.el7.x86_64 conflicts Percona-XtraDB-Cluster-shared-56
--> Processing Conflict: Percona-XtraDB-Cluster-shared-compat-57-5.7.28-31.41.1.el7.x86_64 conflicts Percona-XtraDB-Cluster-shared-55
--> Processing Conflict: Percona-Server-shared-56-5.6.47-rel87.0.1.el7.x86_64 conflicts Percona-Server-shared-55
--> Finished Dependency Resolution
Error: Percona-XtraDB-Cluster-shared-57 conflicts with Percona-Server-shared-56-5.6.47-rel87.0.1.el7.x86_64
Error: Percona-Server-shared-55 conflicts with Percona-Server-shared-56-5.6.47-rel87.0.1.el7.x86_64
Error: Percona-XtraDB-Cluster-shared-56 conflicts with Percona-Server-shared-56-5.6.47-rel87.0.1.el7.x86_64
Error: Percona-Server-shared-56 conflicts with Percona-Server-shared-55-5.5.62-rel38.14.el7.x86_64
Error: Percona-XtraDB-Cluster-shared-compat-57 conflicts with 1:Percona-XtraDB-Cluster-shared-55-5.5.41-25.12.855.el7.x86_64
Error: Percona-XtraDB-Cluster-shared-55 conflicts with Percona-Server-shared-55-5.5.62-rel38.14.el7.x86_64
Error: Percona-Server-shared-compat-57 conflicts with Percona-Server-shared-55-5.5.62-rel38.14.el7.x86_64
Error: Percona-XtraDB-Cluster-shared-compat-57 conflicts with 1:Percona-XtraDB-Cluster-shared-56-5.6.46-28.38.1.el7.x86_64
Error: Percona-Server-shared-compat-57 conflicts with Percona-Server-shared-56-5.6.47-rel87.0.1.el7.x86_64
Error: Percona-XtraDB-Cluster-shared-55 conflicts with 1:Percona-XtraDB-Cluster-shared-56-5.6.46-28.38.1.el7.x86_64
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

And then yum exits without installing anything. Unfortunately, I don’t know a ton about how yum or rpm work under the hood, and I’ve yet to get a response from anyone on Percona’s community forum on any topic, so I thought I’d ask here to see if anyone knows a bunch about yum / rpm and can help me at least identify the problem, if not solve it. I have a workaround in that if the repo being active causes a problem (it doesn't when DB software is installed on a system, I believe because mariadb-libs has already been replaced) I can disable it during general patching and then reenable it to do a install / upgrade on a specific package, but I’d like this to be more seamless with less manual intervention.

Knowing that they track their version numbers to the MySQL version numbers I first noticed conflicts between rpms of different versions and I thought, “Um, yeah, 5.5 packages and 5.6 packages are going to conflict, particularly the SAME software for different versions”, but I have neither version installed so why would yum throw these conflict errors? And I suppose this is what I’m hoping someone who really knows yum and rpm can explain to me. Should yum complain about conflicts when neither package in the conflict is installed? I understand that all being equal it shouldn’t, but can anyone think of a condition (misconfiguration) where it would? I’ve never seen anything like this before so I have to assume it’s Percona’s error, and I feel if I could understand what the mistake was, I could pull their packages into my own repo and “fix” them so I can avoid having to do something special JUST for Percona updates during patching.

One other thing I tried was, knowing there are multiple versions of software I’m not going to use and can easily pull out of the downloaded copy after I run a reposync, I removed all the 55, 56 and 80 packages leaving me only with the 57 (i.e. MySQL 5.7) related packages that I’m going to actually need. Then I ran a new createrepo to fix the repodata files, did a sudo yum clean all and tried my sudo yum update, again.

This time, I got the following.

Resolving Dependencies
--> Running transaction check
---> Package Percona-Server-shared-compat-57.x86_64 0:5.7.29-32.1.el7 will be obsoleting
---> Package Percona-XtraDB-Cluster-shared-57.x86_64 0:5.7.28-31.41.1.el7 will be obsoleting
---> Package Percona-XtraDB-Cluster-shared-compat-57.x86_64 0:5.7.28-31.41.1.el7 will be obsoleting
---> Package mariadb-libs.x86_64 1:5.5.64-1.el7 will be obsoleted
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================
Package Arch Version Repository Size
======================================================================================================
Installing:
Percona-Server-shared-compat-57 x86_64 5.7.29-32.1.el7 local-percona-release-x86_64 1.2 M
replacing mariadb-libs.x86_64 1:5.5.64-1.el7
Percona-XtraDB-Cluster-shared-57 x86_64 5.7.28-31.41.1.el7 local-percona-release-x86_64 738 k
replacing mariadb-libs.x86_64 1:5.5.64-1.el7
Percona-XtraDB-Cluster-shared-compat-57 x86_64 5.7.28-31.41.1.el7 local-percona-release-x86_64 1.1 M
replacing mariadb-libs.x86_64 1:5.5.64-1.el7

Transaction Summary
======================================================================================================
Install 3 Packages

Total download size: 3.1 M
Is this ok [y/d/N]:

So, better, but still weird. I took a look at the primary.xml in the repodata and those three packages are clearly marked to obsolete mariadb-libs but why would yum want to INSTALL new software to handle an obsoletes directive, particularly when I was asking for a general update? I would understand if I was actually trying to install any one of those packages and it wanted to remove and replace mariadb-libs to satisfy that directive, but why does it want to install 3 pieces of software and do this? It just seems like madness, to me.

So, can anyone with a deeper understanding of yum and rpm than I have help me figure out what’s wrong and if there’s anything I can do from the consumer side to fix this so I can do patching as part of a single sudo yum update? The behaviour is SO weird and SO reproducible (and was referenced by more than 1 third party in https://jira.percona.com/browse/PS-4588 ) that I’m pretty sure it’s a problem on Percona’s end, but as they don’t seem eager to fix it and I still want to use their repo is there anything I can do to fix this on my local repo before my client servers pull their updates?

Any help or suggestions would be appreciated.

Thanks,

Scott

P.S. Forgot to mention that this happens whether I have obsoletes = 0 in the repository configuration file or not.

[TrevorH]

Yes. They've done something stupid and you need to report it to them. I just installed that package on a test VM and it immediately gives the same problems that you have and I don't even have any mysql/mariadb packages installed other than mariadb-libs.

[root@centos7 ~]# rpm -qa mariadb\*
mariadb-libs-5.5.64-1.el7.x86_64
[root@centos7 ~]# repoquery -q --obsoletes Percona-Server-shared-55.x86_64
mariadb-libs
[root@centos7 ~]# repoquery -q --obsoletes Percona-Server-shared-56.x86_64
mariadb-libs
[root@centos7 ~]# repoquery -q --obsoletes Percona-Server-shared-compat-57.x86_64
mariadb-libs
[root@centos7 ~]# repoquery -q --obsoletes Percona-XtraDB-Cluster-shared-55.x86_64
Percona-XtraDB-Cluster-shared
mariadb-libs >= 5.5.37
[root@centos7 ~]# repoquery -q --obsoletes Percona-XtraDB-Cluster-shared-56.x86_64
mariadb-libs >= 5.5.37
[root@centos7 ~]# repoquery -q --obsoletes Percona-XtraDB-Cluster-shared-57.x86_64
mariadb-libs >= 5.5.37
[root@centos7 ~]# repoquery -q --obsoletes Percona-XtraDB-Cluster-shared-compat-57.x86_64
mariadb-libs

Given how useless this is right out of the box, it inspires no confidence here and I would immediately use yum history undo last to back that package and its changes out.

[sawozny]

Thanks for confirming this issue and that it wasn't just a quirk of my environment. I figured it wasn't due to the JIRA ticket I found, but it's nice to get independent confirmation. And yes, there's clearly some bush league errors being made in their repo. I also noticed that for quite a while now the versions in the package descriptions don't match the actual package versions are so there's more evidence they don't know what they're doing.

Unfortunately, reporting their mistakes to them doesn't seem to make any difference (and they've already confirmed they've known about this issue for 2 years now and have parked it for a full year) so I was hoping to get some suggestions on whether or not there was any way to fix my local copy of their repo.

However, I'm not starting to reconsider the use of their software, at all, considering their clear lack of technical accumen. I was hoping to avoid having to integrate mysql and galera, myself from standard package distros, but maybe it's worth it considering the big technical question mark regarding Percona.

Thanks,

Scott

[MartinR]

Just to pick up on one small point. Scott - you are talking about MySQL whilst Trevor is using MariaDB. I don't know if this will affect things.