serg please take a look

MariaDB-compat existed pretty much always, since 5.5. Because of the bug (MDEV-22078) it failed to build specifically on RHEL8 and CentOS8. The bug was fixed in 10.3.23 and 10.4.13.

You don't have to install it on RHEL8, so just don't.

I do not install it, of course - but it still breaks things. Yes, this is how "Obsoletes: " property of an RPM package works:

if you have a package "mysql-libs" installed and if a new package "MariaDB-compat" suddenly comes into the repo (where it had been missing so far), then on your next "yum update" (to patch your OS once a week) you will get MariaDB-compat automatically replacing "mysql-libs" exactly because the former package "obsoletes" the latter. (This is the intended and documented behaviour of "Obsoletes:" in the RPM world.)

Of course, such an update will fail, since "mysql-libs" provides (as in PRM "Provides: ") libmysqlclient.so.21 which is required by a third-party package and is missing in MariaDB-compat. Which means that from this point on you cannot patch your OS automatically, but only manually, painstakingly listing on the yum command line all packages to update - just because "MariaDB-compat" has a wrong and useless "Obsoletes:" in its spec.

So, I still insist that "MariaDB-compat" should not try to obsolete a foreign package.

It should, and in CentOS 6 and 7 it was a required package that any other MariaDB-* package was depending on. Because postfix needed mysql-libs, and installing MariaDB should not remove postfix, it should replace mysql-libs while keeping postfix in a working condition.

I think we can specify that MariaDB-compat obsoletes only mysql-libs < 8.0, I've checked Oracle mysql-community-libs and RedHat's mysql-libs 8.0 packages and it seems there should be no file level conflicts (which was the only reason why we have this "Obsoletes")

This has to wait till the next release, unfortunately.

The fix requires changes in 10.1 metadata (because -compat in 10.4 is just a repackaged 10.1) and while 10.1 metadata don't exactly make sense (it provides mysql-libs = 1:10.1.17-1.el7.centos) it's too risky to change, some packages might require this. As 10.1 was doing it for five years already. But 10.1 reaches EOL in October this year, as soon as we build the last release I'll change the metadata to have -compat packages fixed.

assen.totin, do you mean it worked before 10.4.13? Like, with 10.4.12?

I cannot install mysql-libs-8.0.21 and MariaDB-shared-10.4.16 in parallel on RHEL8 even without MariaDB-compat.
Because MariaDB-shared requires MariaDB-common of the same version and mysql-libs require mysql-common of the same version.
And two *-common packages conflict, they cannot be installed in parallel.

So how did you manage to do it with 10.4.12?

Here is what I have on a real-life system:

root@cgdczbx1 assen.totin]# cat /etc/redhat-release 

Red Hat Enterprise Linux release 8.2 (Ootpa)

[root@cgdczbx1 assen.totin]# rpm -qa | grep -i mysql

zabbix-server-mysql-5.0.4-1.el8.x86_64

zabbix-web-mysql-5.0.4-1.el8.noarch

php-mysqlnd-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64

mysql-libs-8.0.17-3.module+el8.0.0+3898+e09bb8de.x86_64

[root@cgdczbx1 assen.totin]# rpm -qa | grep -i mariadb

MariaDB-server-10.4.15-1.el8.x86_64

MariaDB-common-10.4.15-1.el8.x86_64

MariaDB-shared-10.4.15-1.el8.x86_64

MariaDB-client-10.4.15-1.el8.x86_64

MariaDB-backup-10.4.15-1.el8.x86_64

It does take some wiggling because MariaDB packages are still not modular and therefor YUM hides them if either mysql or mariadb module is enabled - so they both have to be disabled in order to install MariaDB, but the mysql module will need to be enabled (back) in order to install their package (which becomes a hard dependency for Zabbix since our version of libmysqlclient.so is too old for them).

I had the system installed with 10.4.12 and on the upgrade to 10.4.13 it broke, so I had to do something like this; after that upgrade have been going fine and I'm now on 10.4.15:

[root@cgdczbx1 assen.totin]# cat /etc/yum.conf 

...

exclude=MariaDB-compat