Bug#1020518: [debian-mysql] Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf
On Thu, Sep 22, 2022 at 06:21:34PM +0200, Ghislain Adnet wrote: > So perhaps we could see it another way : > in this particular case i think that a client library, if it find an existing > /etc/mysql/my.cnf, should not do anything as it is there adn so everything it > need is okay. > There is no need for a client library to change this part if it is here if it > only need one to exist. > > Perhaps just adding a check > if [[ ! -e /etc/mysql/my.cnf ]]; then > do touch server configuration in /etc/mysql/my.cnf > fi We use the Debian-system-wide update-alternatives mechanism, which has standard and known behaviour. Further, third party packaging can simply integrate with it to provide their own my.cnf as needed. If /etc/mysql/my.cnf is properly overriden by packaging, even external packaging, then the client library packages that touch it will leave it alone. I don't think it makes sense to introduce extra behaviour that might be surprising for sysadmins who already know how update-alternatives works and integrate with it. Again, note that I'm still speculating here because I don't follow the exact sequence of events which is causing the third party packaging to trip up here. If there's something we're doing wrong then we should fix it, but nothing I've read so far suggests that. signature.asc Description: PGP signature
Bug#1020518: [debian-mysql] Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf
Le 22/09/2022 à 18:12, Robie Basak a écrit : On Thu, Sep 22, 2022 at 05:10:05PM +0200, nobody wrote: * What outcome did you expect instead? installing a client library should not require anything on the server side and should not modify server configuration of mariadb or other mysql flavors (imho ;p) Both MySQL/MariaDB client libraries and MySQL/MariaDB daemons expect and use /etc/mysql/my.cnf, and many common packages supplied by Debian link to a MySQL/MariaDB library. So Debian ends up needing to ship a working /etc/mysql/my.cnf essentially by default. It doesn't matter which side of the fork is in use - it's necessary either way. Maybe upstream could separate the two out, but they don't. thanks for your quick answer So perhaps we could see it another way : in this particular case i think that a client library, if it find an existing /etc/mysql/my.cnf, should not do anything as it is there adn so everything it need is okay. There is no need for a client library to change this part if it is here if it only need one to exist. Perhaps just adding a check if [[ ! -e /etc/mysql/my.cnf ]]; then do touch server configuration in /etc/mysql/my.cnf fi -- cordialement, Ghislain ADNET.
Bug#1020518: [debian-mysql] Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf
On Thu, Sep 22, 2022 at 05:10:05PM +0200, nobody wrote: >* What outcome did you expect instead? > >installing a client library should not require anything on the server side > and should not modify server configuration of mariadb or other mysql flavors > (imho ;p) Both MySQL/MariaDB client libraries and MySQL/MariaDB daemons expect and use /etc/mysql/my.cnf, and many common packages supplied by Debian link to a MySQL/MariaDB library. So Debian ends up needing to ship a working /etc/mysql/my.cnf essentially by default. It doesn't matter which side of the fork is in use - it's necessary either way. Maybe upstream could separate the two out, but they don't. MySQL and MariaDB Debian maintainers worked out a way to make it work regardless of the side of the fork in use using the update-alternatives mechanism. I think there might still be some implementation bugs in how they do that exactly, but I don't think they're relevant to what you're reporting here. If third parties are shipping apt packages that override some of this, they need to integrate with distribution packages, not the other way round. Issues with third party apt repositories aren't normally considered bugs in Debian. This sounds like an issue with a third party repository and a bug in their packaging, and not a bug in Debian. However I'm not entirely sure as you haven't provided a detailed analysis of why they've been unable to integrate. I suggest that this bug needs to be either moreinfo or wontfix. signature.asc Description: PGP signature
