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

[Otto Kekäläinen]

Hello!

Thanks Andreas for driving mysql-common split-out. Below are my
comments to your thoughts:

2015-07-24 3:45 GMT+03:00 Andreas Beckmann <anbe at debian.org>:
> 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.

Keeping the name mysql-common is OK. The variants are after all mysql
based, so using the name mysql is OK both now and in the foreseeable
future too.

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

No that I am aware of.

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

Maybe just stick to the basic thing here and not start
over-engineering. If we get an independent mysql-common package and we
already have the virtual-mysql- scheme in use, then these tools can be
used to meet all current needs.

> * 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)

There is always also the option to add Provides: mysql-server into the
mariadb packages to do a quick transition if needed. Somehow I think
that simpler is better, and adding an extra layer of
defaul-something-packages is against simplicity, while the gain is
rather small. Also there are certain benefits that packagers review
their dependencies and change them on purpose, as they are more likely
to also consider their use case and suitability in those cases.

- Otto