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

[Otto Kekäläinen]

Hello!

Report of status and request for comments from the release team
regarding the next steps:

2016-04-11 21:38 GMT+01:00 Otto Kekäläinen <otto at seravo.fi>:
> 1. MariaDB as default

On the pkg-mysql-maint team we have discussed providing a new scheme
to complement the existing virtual-mysql-* scheme. We plan to
introduce new purely virtual packages, that are provided only by
MariaDB:
- default-mysql-client
- default-mysql-client-core
- default-mysql-server
- default-mysql-server-core
- default-libmysqlclient

(the last item on the list is my own addition, see point 3 below)

Once these are available we would announce them on debian-devel@ and
ask all packagers to update existing "Depends: mysql-*" to "Depends:
default-mysql-*"

If release team whished to switch defaults, then it is just a matter
on deciding which package shall provide these default-mysql-* virtual
packages. This is how e.g. default-mta works and is provided by
Postfix.


> 2. mysql-common and configuration

The pkg-mysql-main team has been working to create a new source
package 'mysql-defaults', which will produce the mysql-common binary
package, which provides the configuration facilities etc that both
mysql-* and mariadb-* binary packages use. This is mostly an
refactoring effort, taking out current mysql-common from the mysql-5.6
source package into a new source package that is independet.


> 3. libmysqlclient.so.18

Here theres's no concensus yet within the pkg-mysql-maint team on this one.

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 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.

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 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.

- Otto