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
signature.asc
Description: PGP signature