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

[Norvald H. Ryeng]

On Fri, 24 Jul 2015 02:45:27 +0200, Andreas Beckmann <anbe at debian.org>  
wrote:
> 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?

I don't think so.

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

There shouldn't bee many packages depending on the server (they may  
suggest or recommend it, though). The only two I can think of are akonadi  
and cqrlog. Both have modes where they, instead of connecting to a remote  
server, start their own mysqld on a non-standard port. Most other packages  
just depend on a client library and will connect to any server that  
supports the MySQL protocol.

Plugins would depend on the server, but I wouldn't trust that they would  
work with any other version of the server than the one they were compiled  
with. If you want to package the same third-party plugin for MySQL and  
MariaDB, I recommend separate mysql-plugin-foo and mariadb-plugin-foo  
packages.

I don't think it makes sense to make a virtual testsuite package.

See below for comments about default-whatever-server.

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

No, there's no name for it. There's only one MySQL Server, but there are  
other DBMSs, like MariaDB and Percona, that claim to support the MySQL  
protocol. The "virtual-mysql-server" represents this concept. It's not a  
very good name for it, but it does the job.

In the packaging team, we've recently started using "variant" for what you  
call "implementation". The upstream term is usually "MySQL and forks".

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

At the moment, that's probably mostly true. They just want something that  
speaks the MySQL protocol on a network port/UNIX socket. I know MySQL  
Workbench will complain if it connects to MariaDB and you try to use  
features that are only in MySQL, but most packages probably use only a  
common subset of functionality.

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

As explained above, there shouldn't be that many packages that depend on  
the server. But there may be more that suggest or recommend the server  
package.

I see what you want to do with the default-whatever-server package. We've  
discussed this before, when introducing the virtual-mysql-* packages, and  
ended up with not wanting to pick a default. Instead, it's up to the  
maintainer of each client application package maintainer to set the  
default for that package. E.g., it would be silly to have MariaDB as the  
default for MySQL Workbench when it needs MySQL Server in order to use all  
features.

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

Please don't "hijack" the mysql-server package name. It's needed to refer  
to the current mysql-server-x.y package. I think the virtual-mysql-server  
package is the one we should use for the concept of "something MySQL-like".

Regards,

Norvald H. Ryeng