Debconf `percona-server-server/existing_config_file` not taken into account when upgrade

MySQL & MariaDB
1

On debian /var/lib/dpkg/info/percona-server-server.postinst:

case "$1" in
        configure)

        if [ -z "$2" ];
        then
                …
        else
                # If the existing config file is a proper file, we back it up
                if [ -f "/etc/mysql/my.cnf" ] && [ ! -L "/etc/mysql/my.cnf" ]; then
                        cp /etc/mysql/my.cnf /etc/mysql/my.cnf.bak
                        echo "WARNING: /etc/mysql/my.cnf moved to /etc/mysql/my.cnf.bak"
                        echo "Please use etc/mysql/mysql.conf.d for any custom configuration settings"
                fi
                update-alternatives --force --install /etc/mysql/my.cnf my.cnf "/etc/mysql/mysql.cnf" 300
                if [ -f "/etc/apparmor.d/usr.sbin.mysqld" ]; then
                        check_apparmor_files
                else
                        mv -f /etc/apparmor.d/usr.sbin.mysqld.in2 /etc/apparmor.d/usr.sbin.mysqld 2> /dev/null || true
                fi
                rm -f /etc/apparmor.d/old_apparmor
                if aa-status --enabled 2>/dev/null; then
                        apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.mysqld 2>/dev/null || true
                fi
        fi

Which means that debconf:

# Select which my.cnf should be used
# Choices: Use existent my.cnf (RECOMMENDED), Use NEW my.cnf
percona-server-server   percona-server-server/existing_config_file      select  Use existent my.cnf (RECOMMENDED)

isn’t taken into account when doing percona upgrade.

IMHO it’s a bug.

What do you think ?

(I didn’t found the source to provide a PR)

2

Hey @tchernomax.
Could you please provide a bit more information about this case?
What version you are using and what exact commands you execute so we can reproduce this issue

3

My host : Debian 12 (but it should be reproducible on all debian)

# cat /etc/apt/sources.list.d/percona.list
deb http://repo.percona.com/ps-80/apt bookworm main
# dpkg -l percona-server-server
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                  Version              Architecture Description
+++-=====================-====================-============-=======================================
ii  percona-server-server 8.0.40-31-1.bookworm amd64        Percona Server database server binaries
# debconf-get-selections | grep percona-server-server/existing_config_file
percona-server-server	percona-server-server/existing_config_file	select	Use existent my.cnf (RECOMMENDED)
# cat /etc/mysql/my.cnf
!includedir /etc/mysql/ansible.d/
# apt update
# apt install percona-server-server=8.0.45-36-1.bookworm

-> /etc/mysql/my.cnf is replaced by the upgrade (postinst script) and mysql.service is restarted (without all the configuration from ansible)…

In my case, the log_bin was overwritten by ansible, so the upgrade broke my replication.