On Sun, Jul 03, 2016 at 12:46:29PM +0100, Otto Kekäläinen wrote: > 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.
I don't think I understand why you would have both virtual-mysql-* and default-mysql-* packages for dependencies (leaving aside build-deps). If a package requires one of the variants, it will need an explicit dependency. If it doesn't care, it should use the default. Therefore are the virtual-* packages required? As virtual packages provided by >1 package breaks build-dependency handling, if there is any danger that these might be used in build-depends they should be meta-packages, not virtual. > > 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). Yes. > 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. We discussed this in the release team and concluded that having two libmysqlclient.so.18 files in two packages is likely to run into problems later if/when they diverge, so there is no point delaying that pain. Especially as they are not identical even now. I wonder if pkgconfig can be any help here? That involves a one-time change to client packages if they don't already use pkgconfig but doesn't have to be repeated if the default switches. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
