[debian-mysql] splitting out mysql-common (was: Re: Future general packaging improvements )

[Andreas Beckmann]

On 2015-07-23 23:14, Otto Kekäläinen wrote:
> Anticipating that it will take some time for mysql-5.6 to pass from
> unstable to testing successfully, and as the mysql-common 5.6
> dependency in mariadb will block new mariadb versions from entering to
> testing for a long time, I would be favour in making the mysql-common
> a separate source package rather sooner than later.

But that split out mysql-common cannot overtake mysql-5.6 (unless it
kicks mysql-5.5 out of testing).
So let's see that we get this transition finished as fast as possible.

> Andreas: as the pkg-mysql-team is rather short on contributors, could
> you please stay around and also help out by making the mysql-common a
> separate new source package?

Hmm, maybe ;-) But I will only look at the packaging side, ideally as an
advisor. I don't want to touch SQL or source code. :-P


For splitting out mysql-common ...
here are some thoughts from me, I have absolutely no background in any
discussions you already may have had on this topic. And no background in
general mysql-foo packaging either.

* the package name is a bit unfortunate since it refers to one specific
implementation, but renaming it would turn switching to my.cnf managed
by configure-symlinks into hell. Reconsider a rename for stretch+2.

* are there any other metapackages that should be split out as well?

* should there be new metapackages introduced?
  I could imagine something like default-${whatever}-server (or
  ${whatever}-default-server) and the same for client and maybe
  testsuite  (similar to mpi-default-{bin,dev}, even though the
  defaults there vary between platforms)

* do you have a good name to describe the "concept" of a mysql server,
i.e. for the ${whatever} above while there are different
"implementations" of a mysql server, e.g. "mysql", "mariadb", "percona"

* as I understand it for most applications that just need the "concept"
of a mysql server it should not matter which "implementation" is running

* many packages depend (historically grown) on "mysql-server" or maybe
"mariadb-server | mysql-server" or in combination with the recently
added virtual-mysql-server as "mysql-server | virtual-mysql-server" to
allow any alternate implementation. But these users should ideally not
enumerate implementations but the concept via
  Depends/Rcmds/Suggs: default-whatever-server | virtual-mysql-server
(therefore default-whatever-server needs to be a real package)
Such a switch would involve quite a lot of packages and take some time,
but it would not be a critical transition where all packages must have
"been rebuilt" at some point in time to migrate all together. That could
happen gradually instead.

* having such separate default-whatever packages would simplify
switching this default, e.g. if release or security team declare a
preference for one implementation.
right now the meaning of the "mysql-server" package would have to be
changed from "implementation" to "concept"
(in my understanding "mysql-server" and "mariadb-server" mean "the
default version of the respective implementation", and having the actual
implementations versioned is OK, but there should be at most one version
of an implementation per release)


Andreas