[Maria-developers] libmysqlclient.so and Fedora-specific symbol versioning
Hi guys, I'm writing this as a maintainer of MariaDB package in Fedora and RHEL. I've got some complaints about libmysqlclient symbols versioning in Fedora and future RHEL-7: https://bugzilla.redhat.com/show_bug.cgi?id=1045013 Simply put, the issue there is that RPMs (both made by MariaDB upstream or Fedora community) uses different symbol versioning than it is used in other distributions (deb packages, binary tar balls) or by other MySQL providers (Oracle, Percona). Fedora does it because it used to be done that way before and it was not changed at a time upstream changed that, since Fedora started to handle symbols list on its own. MariaDB upstream adopted Fedora's behavior as a resolution of the bug: https://mariadb.atlassian.net/browse/MDEV-3923 As a result, we have different versioning only based on packaging format now, which seems to be a problem. So, I'd like to propose to sync this gap between "RPM-based packages" and "rest of the world" in the future Fedora/RHEL releases, which basically means I'd like to ask: In case Fedora 21 and RHEL-7 adopt non-versioned symbols in libmysqlclient, would MariaDB upstream be able to do the same in RPMs for these releases? There is also second difference between RPM and non-RPM builds, which is that only limited subset of symbols (those that are documented as API) is exported in the client library in Fedora RPMs. This is because we believe exporting all symbols is wrong thing. Regarding this issue, we'd like to keep the limited set of symbols in RPMs, so, the only change I'm proposing to change versioning of these symbols (as described above). Primarily, I'd like to hear what MariaDB upstream's position on that is, if the sync can happen, but any ideas will be welcome. Honza
Hi, Honza! On Jan 07, Honza Horak wrote:
I'm writing this as a maintainer of MariaDB package in Fedora and RHEL. I've got some complaints about libmysqlclient symbols versioning in Fedora and future RHEL-7: https://bugzilla.redhat.com/show_bug.cgi?id=1045013
Simply put, the issue there is that RPMs (both made by MariaDB upstream or Fedora community) uses different symbol versioning than it is used in other distributions (deb packages, binary tar balls) or by other MySQL providers (Oracle, Percona).
Fedora does it because it used to be done that way before and it was not changed at a time upstream changed that, since Fedora started to handle symbols list on its own. MariaDB upstream adopted Fedora's behavior as a resolution of the bug: https://mariadb.atlassian.net/browse/MDEV-3923
As a result, we have different versioning only based on packaging format now, which seems to be a problem. So, I'd like to propose to sync this gap between "RPM-based packages" and "rest of the world" in the future Fedora/RHEL releases, which basically means I'd like to ask: In case Fedora 21 and RHEL-7 adopt non-versioned symbols in libmysqlclient, would MariaDB upstream be able to do the same in RPMs for these releases?
Yes. Unless users start filing compatibility bugs after this change and then we'll need to figure something out.
There is also second difference between RPM and non-RPM builds, which is that only limited subset of symbols (those that are documented as API) is exported in the client library in Fedora RPMs. This is because we believe exporting all symbols is wrong thing. Regarding this issue, we'd like to keep the limited set of symbols in RPMs, so, the only change I'm proposing to change versioning of these symbols (as described above).
Primarily, I'd like to hear what MariaDB upstream's position on that is, if the sync can happen, but any ideas will be welcome.
I believe, Fedora's way is the correct one. Symbols that weren't changed from libmysqlclient.so.16 should have libmysqlclient_16 version, new or modified symbols should have libmysqlclient_18 version. This way old applications that only use libmysqlclient_16.* symbols will continue working just fine. What is the point of versioning if all symbols have the same version - if the version cannot be used to distinguish symbols, one can as well use no version at all. But anyway, we've started to use Fedora versioning script for compatibility reasons. If Fedora will start to version symbols differently, we'll follow. Regards, Sergei
Hi, Honza! On Jan 07, Sergei Golubchik wrote:
On Jan 07, Honza Horak wrote:
Primarily, I'd like to hear what MariaDB upstream's position on that is, if the sync can happen, but any ideas will be welcome.
I believe, Fedora's way is the correct one. Symbols that weren't changed from libmysqlclient.so.16 should have libmysqlclient_16 version, new or modified symbols should have libmysqlclient_18 version. This way old applications that only use libmysqlclient_16.* symbols will continue working just fine.
What is the point of versioning if all symbols have the same version - if the version cannot be used to distinguish symbols, one can as well use no version at all.
Another thought - as Fedora is the only one that did the symbol versioning in libmysqlclient correctly, it'd be a pity to revert that for compatibility with incorectly versioned libraries. I'd consider doing the following instead (one of or all of that): * report a bug to MySQL about incorrect versioning * report a bug to Debian about incorrect versioning * change the versioning to be correct and debian-compatible, by having old symbols to appear under both libmysqlclient_16 and libmysqlclient_18 version. I don't believe Debian will use Fedora-style versioning, it's an incompatible change after all. But they might want to use "correct-and-compatible" approach with symbol aliases and two versions per symbol. Regards, Sergei
On 01/08/2014 02:25 PM, Sergei Golubchik wrote:
Hi, Honza!
On Jan 07, Sergei Golubchik wrote:
On Jan 07, Honza Horak wrote:
Primarily, I'd like to hear what MariaDB upstream's position on that is, if the sync can happen, but any ideas will be welcome.
I believe, Fedora's way is the correct one. Symbols that weren't changed from libmysqlclient.so.16 should have libmysqlclient_16 version, new or modified symbols should have libmysqlclient_18 version. This way old applications that only use libmysqlclient_16.* symbols will continue working just fine.
What is the point of versioning if all symbols have the same version - if the version cannot be used to distinguish symbols, one can as well use no version at all.
Another thought - as Fedora is the only one that did the symbol versioning in libmysqlclient correctly, it'd be a pity to revert that for compatibility with incorectly versioned libraries.
I'd consider doing the following instead (one of or all of that):
* report a bug to MySQL about incorrect versioning
* report a bug to Debian about incorrect versioning
* change the versioning to be correct and debian-compatible, by having old symbols to appear under both libmysqlclient_16 and libmysqlclient_18 version.
I don't believe Debian will use Fedora-style versioning, it's an incompatible change after all. But they might want to use "correct-and-compatible" approach with symbol aliases and two versions per symbol.
Sergei, thanks a lot for both your advices, I'll try that. Anyway, do you happen to know from scratch how to define two versions for one symbol in the version script (what is the syntax)? I'm quite lost right now, but maybe you have experiences with it. Honza
Hi, Honza! On Jan 08, Honza Horak wrote:
* change the versioning to be correct and debian-compatible, by having old symbols to appear under both libmysqlclient_16 and libmysqlclient_18 version.
I don't believe Debian will use Fedora-style versioning, it's an incompatible change after all. But they might want to use "correct-and-compatible" approach with symbol aliases and two versions per symbol.
Sergei, thanks a lot for both your advices, I'll try that. Anyway, do you happen to know from scratch how to define two versions for one symbol in the version script (what is the syntax)? I'm quite lost right now, but maybe you have experiences with it.
I didn't try it myself. But in the ld info pages they mention that it's possible. Info pages have an example, but it uses __asm__ and .symver, not a linker script. I think one can do the same with a linker script. Regards, Sergei
On 01/08/2014 06:10 PM, Sergei Golubchik wrote:
Hi, Honza!
On Jan 08, Honza Horak wrote:
* change the versioning to be correct and debian-compatible, by having old symbols to appear under both libmysqlclient_16 and libmysqlclient_18 version.
I don't believe Debian will use Fedora-style versioning, it's an incompatible change after all. But they might want to use "correct-and-compatible" approach with symbol aliases and two versions per symbol.
Sergei, thanks a lot for both your advices, I'll try that. Anyway, do you happen to know from scratch how to define two versions for one symbol in the version script (what is the syntax)? I'm quite lost right now, but maybe you have experiences with it.
I didn't try it myself. But in the ld info pages they mention that it's possible. Info pages have an example, but it uses __asm__ and .symver, not a linker script. I think one can do the same with a linker script.
Our gcc/ld gurus told be we have to use __asm__ and .symver actually. Anyway, Oracle uses it already for their Fedora builds: http://bazaar.launchpad.net/~mysql/mysql-server/5.6/view/head:/packaging/rpm... Also, I tried to summarize what our options are in https://bugzilla.redhat.com/show_bug.cgi?id=1045013#c12 ..feel free to add your points there. Good thing is that if we start using "correct-and-compatible" approach with symbol aliases and two versions per symbol, we're not blocked by Debian approach, since adopting the same one would make things a bit better, but even non-adoption it doesn't make it much worse. Regards, Honza
On 01/08/2014 06:10 PM, Sergei Golubchik wrote:
Hi, Honza!
On Jan 08, Honza Horak wrote:
* change the versioning to be correct and debian-compatible, by having old symbols to appear under both libmysqlclient_16 and libmysqlclient_18 version.
I don't believe Debian will use Fedora-style versioning, it's an incompatible change after all. But they might want to use "correct-and-compatible" approach with symbol aliases and two versions per symbol.
Sergei, thanks a lot for both your advices, I'll try that. Anyway, do you happen to know from scratch how to define two versions for one symbol in the version script (what is the syntax)? I'm quite lost right now, but maybe you have experiences with it.
I didn't try it myself. But in the ld info pages they mention that it's possible. Info pages have an example, but it uses __asm__ and .symver, not a linker script. I think one can do the same with a linker script.
I've created a bug report with a patch that we're going to use in RHEL-7 probably. If anybody has some points/ideas for improvement, please, comment. https://mariadb.atlassian.net/browse/MDEV-5529 Honza
participants (2)
-
Honza Horak -
Sergei Golubchik