New -compat RPM package breaks certain upgrades

With 10.4.13 MariaDB RPM repositories introduced a new package, MariaDB-compat. While the idea of changing packaging amidst a stable mainline is already ridiculous, this new package breaks MariaDB upgrade whenever a hybrid, MariaDB + MySQL system is present. The change is completely unannounced and, its present form, does more harm than good.

There are real-life cases when a vendor links its product to specific versions of libmysqlclient which are not provided by MariaDB. One such example is Zabbix. Version 4 required libmysqlclient 20 and version 5 requires libmysqlclient 21. For both of these to run, one had to install real MySQL packages - either from Oracle (on RHEL-7) or from RedHat (on RHEL-8). To make it clear, MariaDB still only ships libmysqlclient 18 as of MariaDB-common-10.4.13.

Since MariaDB packaging does not conflict with neither Oracle's nor RedHat's one for MySQL, it was quite possible to have on the same OS instance a MariaDB server alongside a client that is forced to use MySQL libraries (e.g., Zabbix server connecting to a local MariaDB server).

Typically, the -compat packages provide older version of a given library for older software to work with; glibc-compat and g++-compat are well known examples. Thew newly introduced MariaDB-compat provides libmysqlclient 15, 16 and 18. While these may be needed, it also obsoletes a package named mysql-libs, which is - intentionally? - the name of the MySQL's package that contains the current version of libmysqlclient, 21.Therefore we now have a -compat package with older versions of a library which removes another package with the current version of the same library. This is, of course, quite a bad behavior.

The quick solution for such cases is to blacklist the MariaDB-compat package which is useless anyway. Long term, however, MariaDB should fix its packaging and not obsolete a foreign package which provides a more current version of the same library.