Bug#850216: [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 Sun, Jan 15, 2017 at 09:33:24PM +0200, Otto Kekäläinen wrote:
> 2017-01-13 13:18 GMT+02:00 Robie Basak :
> > So I think the configure-symlinks code needs to move from mariadb-common
> > to mariadb-server-10.1 in addition.
> 
> The MariaDB client programs might also have MariaDB specific
> configuration lines, which according to this new config scheme should
> be placed in /etc/mysql/mariadb.cnf.d/, and for them to be read,
> mariadb-common must control the configure-symlinks.

OK.

> Maybe we should mark both the client and server packages to conflict
> each other, and for mariadb-common to conflict on mysql-client and
> mysql-server?

I think your statement above means that this must happen. Anything that
requires a custom /etc/mysql/my.cnf (rather than the generic one
provided in src:mysql-defaults) necessarily *must* conflict with
anything else that requires a different custom /etc/mysql/my.cnf.

I wonder if we should have both mariadb-common and mysql-server-5.7 (ie.
everything that asks for a custom my.cnf symlink) declare a virtual
package? So add:

  Provides: mysql-my-cnf
  Conflicts: mysql-my-cnf

to both mariadb-common and to mysql-server-5.7.

To be clear, mysql-common would not change. It would continue to provide
the "default" symlink for my.cnf for packages that want them, and we
should continue to negotiate any changes needed to that.

The rule would be: any package that arranges a /etc/mysql/my.cnf
symlink, usually via /usr/share/mysql-common/configure-symlinks, MUST
Provide and Conflict mysql-my-cnf, with the exception of mysql-common.

Then we wouldn't have to track individual conflicts related to my.cnf. I
think apt should be able to figure things out then, right?

Robie


signature.asc
Description: PGP signature

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

[Otto Kekäläinen]

Hello!

2017-01-13 13:18 GMT+02:00 Robie Basak :
> So I think the configure-symlinks code needs to move from mariadb-common
> to mariadb-server-10.1 in addition.

The MariaDB client programs might also have MariaDB specific
configuration lines, which according to this new config scheme should
be placed in /etc/mysql/mariadb.cnf.d/, and for them to be read,
mariadb-common must control the configure-symlinks.

Maybe we should mark both the client and server packages to conflict
each other, and for mariadb-common to conflict on mysql-client and
mysql-server?



-- 
Otto Kekäläinen
https://keybase.io/ottok
Seravo Oy and MariaDB Foundation

Bug#850216: [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,

Thank you for working on this.

On Fri, Jan 13, 2017 at 01:05:49AM +0200, Otto Kekäläinen wrote:
> Fixed as suggested in
> https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.1.git/commit/?id=75fa84af6bdf84ff95bd0cabb2a8966330d77154

I don't think this fix is sufficient. Though it may work in common use
cases, I think that it needs to be impossible for MariaDB packaging to
activate the my.cnf symlink for mariadb.cnf except when one of the
server packages is installed. Because it's only the server packages that
conflict with each other across the variants, and this is the only
mechanism preventing both mariadb.cnf and mysql.cnf being activated at
once.

Otherwise, for example, I could still install mariadb-common on a system
with mysql-server-5.7 installed, and it would still mess up.

So I think the configure-symlinks code needs to move from mariadb-common
to mariadb-server-10.1 in addition.

Robie


signature.asc
Description: PGP signature