[debian-mysql] Bug#850216: Bug#850216: Bug#850216: mysql-server-5.6: Listens on * by default after installation (related to use of alternatives)

[Robie Basak]

Hi Otto,

On Fri, Mar 10, 2017 at 05:09:42PM +0200, Otto Kekäläinen wrote:
> I wonder if this really is how update-alternatives should be used and
> is really adding conflicts between all packages that use it the smart
> way to utilize the flexibility the update-alternatives scheme should
> provide.

My original logic was as follows:

Some clients may use libmysqlclient from MySQL, and some from MariaDB.
The "mysql" CLI is just another client for this purpose. Clients are
configured from /etc/mysql/my.cnf, and so ideally both MySQL and MariaDB
client libraries can work concurrently. My understanding was that some
minimal client configuration is relevant to install by default, but this
default could be shared by both MySQL and MariaDB. So this can be
shipped by mysql-common, and be active when only clients (no servers)
are in use.

We already expect that the MySQL and MariaDB server daemons cannot both
be active concurrently on the same system - if nothing else but for
grabbing the default port. This can of course be expressed with a simple
Conflicts, or with a more complicated virtual package Provides/Conflicts
(but that's not the question being discussed here).

MySQL and MariaDB diverge in their configuration needs far more when
using their server daemons, but they still expect to share this
configuration with clients in /etc/mysql/my.cnf.

Therefore, we end up in a situation where:

1) When only clients are installed, /etc/mysql/my.cnf can be shared
between clients of both variants, which works well as we do want to be
able to support this.

2) When a daemon is installed, /etc/mysql/my.cnf must specialise to the
variant that is used.

So, it made sense to me that /etc/mysql/my.cnf should be a symlink,
managed by mysql-common for the common client case, but overridable by a
variant-specific daemon package when a daemon is installed.

If the above statements are still true, then I think using
update-alternatives is still the best way to manage this, because it
provides the convenient mechanism for a daemon to be able to override
the default client configuration provided by mysql-common.

I'm not sure that all of this is still true though, as things between
the forks diverge, particularly in MariaDB. I was surprised to learn
that MariaDB clients need their own customised configurations, for
example, and can no longer use a shared configuration shipped by
the mysql-common package. Perhaps then they should be using
/etc/mysql/mariadb.cnf or something instead, though. Could you perhaps
elaborate on the need for this so we can review whether the
update-alternatives mechanism will still work for us?

If on the other hand there are no further complications, I think the
only thing we need to do is make sure that multiple specialised
/etc/mysql/my.cnf paths are not attempted to be provided at once, and
the problem is solved. The natural way to do this is with Conflicts,
regardless of whether we use update-alternatives or some other
mechanism. Even if we were to drop the use of update-alternatives, I
think we would still need the Conflicts that I'm suggesting. I think
this demonstrates that Conflicts as I've proposed is the correct answer
in this case.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20170330/21af3943/attachment.sig>