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
