Symbol versioning in RPM packages

Hi guys,

I’m writing this as a maintainer of MariaDB in Fedora and upcoming RHEL-7. We’ve got some complaints (from MySQL upstream actually) about how we handle symbol versioning in our distros; which we evaluated as valid in the end. The issue is we’ve changed ABI of MySQL client library downstream since MySQL-5.5 in Fedora (in order to prevent upstream’s ABI mistakes), which started to make problems for people building on one distro and running their software on other distro. Detailed info and whole story BZ 1045013 [1].

With collaboration of MariaDB upstream, Oracle developer and us we came up with a solution, that we’ll use both libmysqlclient_16 and libmysqlclient_18 versions for symbols, which were already in MySQL 5.1, while libmysqlclient_18 will be default one. That’s what we’re going to do in RHEL-7, future Fedoras and both MariaDB/MySQL upstreams seem to be willing to use the same approach for RPM packages they provide. I’d like to see what Percona upstream is thinking about this approach and if you guys will be able to adopt the same template at least for RPM packages.

Please, give us also know if somebody sees a problem with the proposed solution.



Honza, Thank you for your question. We’re discussing this internally. If there is no response back by the end of this week, feel free to ping me on Skype @ roel.mysql

Hi Roel,

Any update on this? I was bit by this bug today, when installing Percona 5.6 on RHEL7 - specifically, libmysqlclient_16 isn’t included in the 56 symbol versioning for, which has lead me to needing to downgrade to Percona-Server-shared-55 on clients in order to continue to use applications looking for that symbol version (which is provided in distribution-provided mariadb-libs).

Could we possibly get the _16 symbols compiled in for 5.6 the same way they are for 5.5 on RHEL7?


@ksnider - Thanks. Whilst I am no longer responsible for this area, I do know the discussion is still ongoing internally. No final decision has been made on this. I will ask our packaging engineer to respond on this one. Thank you!