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