[debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*

Clint Byrum spamaps at debian.org
Fri Jul 8 14:12:23 UTC 2016


Excerpts from Otto Kekäläinen's message of 2016-07-03 12:46:29 +0100:
> > 3. libmysqlclient.so.18
> 
> Here theres's no concensus yet within the pkg-mysql-maint team on this one.
> 

And IMO, there won't be one until MariaDB accepts that they've created a
forked library that is API-incompatible with libmysqlclient.

> I suggest we extend the mysql-defaults source package to provide a
> real default-mysqlclient-dev metapackage, which other packages can
> build depend on, using versions if needed (just as default-jdk does).
> 
> Current mariadb-10.0 source package does not ship any
> libmariadbclient18 nor libmariadbclient-dev packages at all, as
> previously it was seen as against the policy (but mariadb-5.5 in
> Debian did). I suggest we start producing them now again to make a
> libmysqlclient.so(.18) available from mariadb-10.0.
> 
> Having two libmysqlclient.so.18 files from two different packages is a
> controversial topic. They are not identical so it is ugly to use the
> same name. This is however a necessity dictated by the need to provide
> a drop-in-replacement that can be used directly without going into
> every single clienting program and editing the C headers and soname
> calls.
> 

It's _extremely_ ugly to use this name. MariaDB needs to stop shipping a
library that claims to be libmysqlclient, but is not.

This notion of a drop-in replacement is just a bait-and-switch tactic
(even if it isn't meant to be one). By allowing somebody to build
against a new API without changing their build scripts, it's just
allowing them to accidentally use that new API and then unknowingly be
dependent on symbols only available in the forked library. There's a
different between ABI equality, and ABI compatibility, and IMO, the
former is more important for Debian.

> It should be noted that the Debian packages shipped directly from
> mariadb.org have provided the libmysqlclient.so file since forever and
> there has not been problems and the drop-in-replacement function has
> been fullfilled as expected. All packages that used to depend on
> Oracle MySQL client library have continued to function with the
> MariaDB equivalent when mariadb.org repositories are activated.
> 

There have not been problems that users reported to MariaDB, because
the issue is extremely subtle and subversive. Those users would only
ever know that there was a problem if they wanted to distribute their
code and had another user try to build on libmysqlclient. For the
average MariaDB user, that's not such a big deal, as they may not be
distributing their code. For Debian, we're distributing all of it, and
we have a duty to give users reliable software. We don't want to build
against libmariadbclient-dev-compat and then the software just doesn't
work with libmysqlclient.so.18 from MySQL.

> It should also be noted that the soname version number 18 has been
> used in Oracle MySQL for a long time without bumping it despite
> changes in the API. The API changes have also gone undocumented all
> the time as the libmysqlclient18 package does not have .symbols file.
> Oracle has finally bumped the soname version to 20 in MySQL 5.7. The
> number 19 is not used anywhere, but was left as something that can be
> resorted to in 5.6, in case somebody would complain too much that 5.5
> and 5.6 API differ but have same version number. No one has, so for
> all practical purposes, the current situation is OK.
> 

The past was horrible, and MySQL obviously did weird things and our
packages were not sufficient to police this properly. But that doesn't
change the fact that MariaDB has hijacked the mysqlcient soname.

> The solution I suggest works nicely in the scope of
> libmysqlclient18/libmariadbclient18 and is resilent for scenarios
> where libmysqlclient20 is introduced or where even more client
> libraries are available (mainly libmariadb2), but I won't go into the
> details of those now, as I think here is enough information to decide
> on whether or not it is OK to provide libmysqlclient.so from a
> libmariadbclient18 package. This would also mean we introduce the
> default-libmysqlclient-dev pmetaackage which depends on either
> libmariadbclient-dev or libmysqlclient-dev package.
> 
> Please comment and advice on how to proceed with packaging to satisfy
> with the switchable defaults requirement.
>

IMO, it's only OK for MariaDB to provide libmysqlclient.so if it is 100%
equivalent to MySQL's libmysqlclient.so. If there are extra API calls,
and extra symbols, it's not the same, and it won't produce a compatible
program linked to libmysqlclient.so.18.



More information about the pkg-mysql-maint mailing list