On Thu, Sep 22, 2022 at 11:32:05PM +0200, Ghislain Adnet wrote: > in fact /etc/mysql/mariadb.cnf does not exist as there is a mysql server and > not a mariadb one.
mariadb-common ships /etc/mysql/mariadb.cnf. > I have a perconna mysql server running and i want to install mytop that > require a perl lib that require libmariad3b, that then, want to replace > /etc/mysql/my.cnf with a link to /etc/mysql/mariadb.cnf, Not necessarily. It integrates with update-alternatives. It will link from /etc/mysql/my.cnf to /etc/mysql/mariadb.cnf unless overridden by another package or by the user. > but /etc/mysql/mariadb.cnf does not exist while /etc/mysql/my.cnf exist from > the percona packages. You're entitled to remove /etc/mysql/mariadb.cnf and I think in that case the packaging should respect that and not break. So there might be something that could be improved here. However, I did some investigation, and found that if you set update-alternatives correctly to use a different my.cnf (in my testing I used my.cnf.fallback as it was already there), then the packaging does not break. So, as far as I can tell, the problem here lies with your third party packaging not correctly integrating with distribution packaging by using update-alternatives correctly to supply my.cnf. I think you need to report this bug to them, and it isn't an issue in Debian.
signature.asc
Description: PGP signature
