The Percona-Server-shared-compat package includes shared libraries for software compiled against older versions of the client library. The following libraries are included in this package: libmysqlclient.so.12, libmysqlclient.so.14, libmysqlclient.so.15, libmysqlclient.so.16, and libmysqlclient.so.18.
I understand why Percona would provide a package with these libraries, but why make it a dependency rather than instruct those using older mysql clients to opt into installing it?
Would you rather have 1,000 people install your software and it just works out of the box, or have 1,000 people opening support tickets asking why the latest version of Percona Server doesn’t work on their system?
If you don’t need it, you can remove it. rpm -e --nodeps
Probably. It’s not hurting anything to leave it there and not causing any other impact.
Well, it installs the compat-openssl10 package, which is affected by a number of CVEs right now. I know we’d only be affected by these CVEs if we were using a MySQL client that requires these older libraries, but it would be nice to have an easy, elegant way to remove the compatibility packages to keep our vulnerability scanner from complaining.
Side note, you do know that 5.7 dies in 40 days right? I’m hoping that this testing is prep for upgrade to 8.0
But the MySQL 8 version of this compatibility package will also be installed as a dependency of the MySQL 8 version of the client. I just used 5.7 as an example since that’s the version my test VM happened to have installed when I started this thread.
This package is not included in downloads for Red Hat Enterprise Linux 9 and derivatives.
Confirmed by spinning up a Rocky 9 VM and installing percona-server-server. Neither the percona compat package nor the openssl compat package were pulled in as dependencies:
