On Monday 2017-12-18 08:48, Simon Becherer wrote:
https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/ "The shared client library is binary compatible with MySQL's client library" ..."All MySQL connectors (PHP, Perl, Python, Java, .NET, MyODBC, Ruby, MySQL C connector etc) work unchanged with MariaDB."
I have not checked *all* the possibilities, but quite a few. 1. Distributions can in their free power patch it to a certain degree that makes it _less_ compatible than what upstream promotes. That is what happened with mysql-community-server. Comparing Leap 42.3's mysql with Factory mariadb 10.1 ("libmysql56client.so.18" vs "libmysqlclient.so.18") shows: [C]'function void mysql_close(MYSQL*)' at client.c:3954:1 has some indirect sub-type changes: linkage names of function void mysql_close(MYSQL*) changed from 'mysql_close@@libmysql56client_18' to 'mysql_close@@libmysqlclient_18, mysql_close@libmysqlclient_16' size of symbol (in bytes) changed from 302 to 114, its version changed from libmysql56client_18 to libmysqlclient_18 Which means if you had a program which requires the ELF symbol "mysql_close@libmysqlclient_16" and you attempted this symlink hack, it should not be able to run on openSUSE's MariaDB, since there is no such symbol anymore. At least it's a verbose failure when it happens. (The results were obtained with abigail tools): abidiff /var/tmp/jng/D2/home/abuild/rpmbuild/BUILD/mysql-5.6.36/build/libmysql/libmysql56client.so.18.1.0 /var/tmp/jng/standard-x86_64/home/abuild/rpmbuild/BUILD/mariadb-10.1.25/build/libmysql/libmysqlclient.so.18.0.0
... the newest mysqlclient (in 8/2017) for maria db was .18 the corrospondung of mysql was 20. so the symlink seems to me correct.
2. subtle change(s) from mysql-5.5 (so.18) to mysql-5.7 (so.20), among it for example: type of 'mysql_option st_mysql_options::methods_to_use' changed: [..] 2 enumerator changes: 'mysql_option::MYSQL_ENABLE_CLEARTEXT_PLUGIN' from value '24' to '36' 'mysql_option::MYSQL_OPT_SSL_MODE' from value '38' to '42' Possibly not part of the public ABI, but who knows..
... since 08/2017 working fine FOR ME without any "known" data corruption.
3. As for silent problems, take for example this 10.1 possible code: mysql->reconnt = 1; In 10.2, this no longer compiles because they have changed the API. And the behavior (the memory at that location is ignored now). But the ABI stayed largely the same. So if you just symlink it, your program believes it is still doing auto reconnects, and if it does not cope with the sudden drops (because people fail to check error codes and fail to test the error paths), it is now susceptible to fall on its own feet now and then break in spectacular ways. So to summarize: - Treat the incompatibility expressed by SONAME changes as exactly that: being incompatibile. And because they are incompatible (at the very least in openSUSE) - there is no drop-in replacement to suggest.
b) why is this not updated automatically if it was installed already (and will be automatically removed)?
Something else might still depend on it. Yes if it is an openSUSE package.
c) how did i find this file using zypper
i tried: zypper se --provides mysqlclient.so.18 libmariadb3-32bit
That seems like a bug, that package has no libmysqlclient in it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org