Bug #92490 mysql-community-8.0 rpms (CentOS7) do not provide libmysqlclient 20 libraries
Submitted: 19 Sep 2018 6:01 Modified: 20 Sep 2018 7:19
Reporter: Simon Mudd (OCA) Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: Packaging Severity:S4 (Feature request)
Version:8.0.12 OS:Any
Assigned to: CPU Architecture:Any
Tags: .so.20, 5.7 compatibility libraries, CentOS7

[19 Sep 2018 6:01] Simon Mudd
I wanted to upgrade 5.7 on my home system to 8.0 as 8.0 is GA.

This gave lots of warnings:

[root@server ~]# rpm -Uvh mysql-community-*.rpm
error: Failed dependencies:
        libmysqlclient.so.20()(64bit) is needed by (installed) bacula-libs-sql-7.4.4-1.el7.centos.x86_64
        libmysqlclient.so.20(libmysqlclient_20.0)(64bit) is needed by (installed) bacula-libs-sql-7.4.4-1.el7.centos.x86_64

I ignored this and just upgraded the rpms to 8.0 but then went to check which libraries are provided by the 8.0 packages:

[root@server ~]# rpm -qa | grep mysql-community
[root@server ~]# rpm -ql mysql-community-libs-compat

and double checking all provided libraries I see:

[root@server data]# rpm -ql $(rpm -qa | grep mysql-community) | grep libmysqlclient

I checked the same against all the mysql-community-5.7 rpms (for CentOS 7) and see these libraries provide .so.18 and .so.20 the latter which my precompiled backups software is looking for.

How to repeat:
check libraries provided from the compat libs for 8.0, compare with 5.7.
See that the default 5.7 libraries are not provided in the compat-libs for 8.0.

Suggested fix:
Please add the missing libraries to mysql-community-lib-compat so I can upgrade to 8.0.
[19 Sep 2018 6:03] Simon Mudd
please do not wait for 8.0.13 to come out to fix this: it is a _packaging_ error, but provide a new mysql-community-libs-compat package which resolves this error (with a new  rpm release tag ) so I can just download it and the upgrade from 5.7 should work providing me with the needed libraries.
[19 Sep 2018 6:18] Daniƫl van Eeden
Looks like the compat packages of 5.7 and 8.0 corectly ship a libmysqlclient.so.18, which is there to replace the MySQL version your OS was shipped with.

And 5.7 gives you libmysqlclient.so.20
And 8.0 gives you libmysqlclient.so.21

So bacula should either link against the version from your OS (libmysqlclient.so.18) or have different packages/builds for 5.7 and 8.0.

Staticaly linking bacula would also fix this.
[19 Sep 2018 7:56] MySQL Verification Team
Hello Simon,

Thank you for the report and feedback.
I discussed this issue internally with Terje, concluded that this is by design and our manual docs were updated to solve such legacy lib dependency issues post Bug #81384.

Under: Installing Client Libraries from Multiple MySQL Versions.


[19 Sep 2018 10:02] Simon Mudd
I'm sorry I disagree.

I moved "up to 5.7" because you provide this as a solution on CentOS 7. this provides libraries which are different to the older system libraries and I chose to link against the current "5.7" libraries which came with the version I installed.

Later I see that 8.0 comes along: Oh great, now I want to use this but I do _not_ want to compile again and rebuild the application (which was working fine) just because I upgrade my MySQL server.  Hence I want 8.0 to include the libraries I compiled against on CentOS 7 which were MySQL 5.7 libraries.  Hence I want 8.0 to include as "compatibility libraries" the library version that came with the OS but also given I could have run 5.7 on CentOS 7 to also include the _extra_ libraries which I used to build software on CentOS 7, in this case the mysqlclient 20 libraries.

If you don't do this then basically you force me to stay on 5.7 which is what I've done now. I've downgraded, because I can't upgrade. I want to run 8.0 and I think that 8.0 should provide the libraries I used when running 5.7.

Could I rebuild the bacula libraries? yes I could. Do I have time? no. Do I want to? No. I just wanted life to be easy and to upgrade MySQL without having to worry about the apps which are _running_ and _working_ on the server.

The other option I could use of course is to statically link everything. I didn't do that, and it has it's own issues if there are bugs in the libraries I'm using as it requires me to recompile the software again.

Basically the current setup puts more onus on the user and requires him to make more of an effort when that is not needed. I do not think that should be necessary.
[19 Sep 2018 10:07] Simon Mudd
If you really want to then you could come up with yet another package: mysql-community-libs-57 which would only confuse people as it would have an rpm name of the form:


That is why I was suggesting you bundle it into the libs-compat rpm. 

This package would contain libraries for MySQL 5.7 that come from the 8.0 rpm set. The package name has to be different to the 5.7 version of the mysql-comunnity-libs  package as you can't (I'd guess) have them both installed at once.
[19 Sep 2018 10:25] MySQL Verification Team
Thank you, Simon for the feedback.
After discussing internally with Terje, verifying this as a feature request since this is a corner case with a documented workaround.

[20 Sep 2018 7:19] Simon Mudd
What is the workaround? That is not clear to me.
[14 Feb 2020 14:42] Reio Remma
Do I understand correctly that mysql-community-libs-compat-8.0 doesn't actually provide compatibility with MySQL-s own 5.7 libs?

Kind of stumped for the same reason on a CentOS 7 that has MySQL 5.7 community server/libs installed.

Is it a technical impossibility to bundle both .so.18 and .so.20 in mysql-community-libs-compat-8.0?