[debian-mysql] factoring out mysql-common

Andreas Beckmann anbe at debian.org
Sat Apr 30 22:05:57 UTC 2016

On 2016-04-28 16:12, Robie Basak wrote:
> Hi Andreas,
> On Fri, Apr 22, 2016 at 08:09:38PM +0200, Andreas Beckmann wrote:
>> Here we go:
>> git://git.debian.org/git/users/anbe/tmp/mysql-defaults.git
> Thank you for doing this for us! I will take a closer look, but my queue
> for MySQL is pretty big at the moment, so a couple of quick things.
>> * needs some Uploaders to be added
>> * maybe debian/copyright could be reduced, probably several people in
>> there never touched mysql-common
>> * maybe needs some bugs to be closed
>> the mysql-5.6 git repo is not up-to-date, otherwise I would have
>> provided a commit for removal of mysql-common
> Sorry! Done now. I wait on the queue accept email before pushing to git,
> but for my last upload it took so long (hours) I forgot all about it.

I do something similar :-) I try to never push a (signed) tag for a
package release before an upload was accepted.

> Please note though that there is a mysql-5.7 tree and our work is
> focused there and is effectively our main development branch now, with
> the 5.6 master branch just being for essential fixes needed before the
> transition. I'm not sure if anything relevant to mysql-common changed in
> 5.7 though but this should probably be checked.

Just verified it. The three trees are completely identical w.r.t. the
bits for mysql-common.

> This confusion is actually a good example of why I think we should have
> a single git tree rather than one per MySQL source package.
> I don't know whether we should do the removal now in 5.6 or wait until
> 5.7 lands (I haven't started this yet). We could always just do both so
> as not to block things.

For 5.7 I'd recommend to drop mysql-common right now and rely on the one
built from 5.6 (until the separated one arrives). This would give
protection from making diverging changes that could be forgotten later
on ...

You can find a single commit removing the mysql-common bits in branch
rm-mysql-common of

(that should apply to 5.7 without problems)

>> PS: and you get default-mysql-{client,server}{,core} for free ;-)
> Do we want this?

That depends on you :-)

> Given that the team doesn't agree on what is default,
> does this serve a useful purpose?

Given that the decision of a default is controversial and may be changed
later on (and might even differ between Debian and Ubuntu) I find it
even more important to have such an intermediate layer (the default-*
packages) between the vendor implementations (mysql-x.y, mariadb-z.w)
and the applications.
I expect the majority of applications using mysql in some way are
agnostic of the actual vendor implementation being used. For these
applications a stable interface should be used such that the change of
the default will not require a sourceful upload to change some
dependencies, but a binNMU after the default-* packages got updated will
Therefore using (Build-)Depends in these applications should follow a
pattern like:
* default-libmysqlclient-dev | virtual-libmysqlclient-dev (if you have a
virtual package there)
* default-mysql-client | virtual-mysql-client
* defualt-mysql-server(-core) | virtual-mysql-server(-core)
and so on.
Only a minority of applications should use dependencies on
vendor-specific implementations (usually applications tightly coupled to
a specific vendor implementation and not usable with any other vendor)
These would leave testing together with their tightly coupled vendor
implementation (in case one vendor implementation has to leave testing).


More information about the pkg-mysql-maint mailing list