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 <robie.ba...@ubuntu.com>: > > 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