oli,

as far as I know the design - you shouldn't think about the shipped config files, instead you have to create custom file under /etc/mariadb.conf.d.
all additional options and overrides should go to custom config file which will survive any upgrade

closing because those config files are just version-specific defaults and shouldn't be edited

otto, is there something we can change in packaging so that when a new my.cnf/mariadb.conf is installed, the old is is preserved as a backup?

Something like RPM's %config, but not like %config(noreplace).
https://www.cl.cam.ac.uk/~jw35/docs/rpm_config.html

Steps to reproduce according to you download page:
https://mariadb.org/download/?tab=repo-config&distro=Debian+10+%22buster%22&ver=10.3&r_mirror=mva

• Fresh Debian 10 minimal
• apt-get install software-properties-common dirmngr apt-transport-https
• apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
• add-apt-repository 'deb [arch=amd64,arm64,ppc64el] https://mirror.mva-n.net/mariadb/repo/10.3/debian buster main'
• apt-get update
• apt-get install mariadb-server
• Change file /etc/mysql/my.cnf

1. ls -ald /etc/mysql/*
   drwxr-xr-x 2 root root 4096 Nov 4 12:05 /etc/mysql/conf.d
   rw------ 1 root root 333 Nov 4 12:05 /etc/mysql/debian.cnf
   -rwxr-xr-x 1 root root 1525 Aug 2 12:58 /etc/mysql/debian-start
   rw-rr- 1 root root 527 Aug 2 12:58 /etc/mysql/mariadb.cnf
   drwxr-xr-x 2 root root 4096 Aug 2 14:33 /etc/mysql/mariadb.conf.d
   rw-rr- 1 root root 5201 Nov 4 12:05 /etc/mysql/my.cnf

• Change file /etc/apt/sources.list from 10.3 to 10.5
• apt-get update
• apt-get upgrade mariadb-server

Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
galera-3 mariadb-client-10.3 mariadb-client-core-10.3 mariadb-server-10.3 mariadb-server-core-10.3
The following NEW packages will be installed:
galera-4 mariadb-client-10.5 mariadb-client-core-10.5 mariadb-server-10.5 mariadb-server-core-10.5
The following packages have been kept back:
linux-image-amd64
The following packages will be upgraded:
base-files bind9-host debconf debconf-i18n distro-info-data krb5-locales libbind9-161 libdns-export1104 libdns1104 libgssapi-krb5-2
libisc-export1100 libisc1100 libisccc161 libisccfg163 libk5crypto3 libkrb5-3 libkrb5support0 liblwres161 libmariadb3 mariadb-common
mariadb-server mysql-common python3-debconf tzdata
24 upgraded, 5 newly installed, 5 to remove and 1 not upgraded.
Need to get 31.6 MB of archives.
After this operation, 15.4 MB of additional disk space will be used.

1. ls -ald /etc/mysql/*

drwxr-xr-x 2 root root 4096 Nov 4 12:05 /etc/mysql/conf.d
rw------ 1 root root 333 Nov 4 12:05 /etc/mysql/debian.cnf
-rwxr-xr-x 1 root root 1731 Aug 3 10:29 /etc/mysql/debian-start
rw-rr- 1 root root 1126 Aug 3 10:29 /etc/mysql/mariadb.cnf
drwxr-xr-x 3 root root 4096 Nov 4 12:09 /etc/mysql/mariadb.conf.d
lrwxrwxrwx 1 root root 24 Nov 4 12:09 /etc/mysql/my.cnf -> /etc/alternatives/my.cnf

--> My changes in my.cnf where gone!

Thanks oli, I have tested and I can confirm the same behavior in containers (Debian10 and Ubuntu20.04).

I did some research and it seems that this was introduced by the following commit:
https://github.com/MariaDB/server/commit/a3448b2395a4f7aff62f8bab70797a6f928d626f
imported from:
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/13e3a7903e5c72e70c02b98a3e51a6de70b9b6ef

I am not sure at this point how we could handle this because it seems that there are various options and I'll wait for otto to comment.

Note that the upgrade from Debian 10.3 version (where /etc/mysql/my.cnf is already a symlink to /etc/alternatives/my.cnf) to MDBF 10.5 version seems to correctly handle this (at least the user receive a warning):

Setting up mariadb-common (1:10.5.12+maria~buster) ...

Configuration file '/etc/mysql/mariadb.cnf'

 ==> Modified (by you or by a script) since installation.

 ==> Package distributor has shipped an updated version.

   What would you like to do about it ?  Your options are:

    Y or I  : install the package maintainer's version

    N or O  : keep your currently-installed version

      D     : show the differences between the versions

      Z     : start a shell to examine the situation

 The default action is to keep your current version.

*** mariadb.cnf (Y/I/N/O/D/Z) [default=N] ? D

Anyway this behavior is not only problematic for users (potential loose of previous configurations), it also does not respect the Debian policy.
From https://www.debian.org/doc/debian-policy/ch-files.html#behavior:

> Configuration file handling must conform to the following behavior:
> - local changes must be preserved during a package upgrade, and
> - configuration files must be preserved when the package is removed, and only deleted when the package is purged.
>
> Obsolete configuration files without local changes should be removed by the package during upgrade.

I agree that a user's config change should be preserved. I don't want the crazy selection of Debian specific defaults partially fixed in 7c2079f600ba to propagate on upgrade. Moving a config file if its content doesn't match a set of hashes (corresponding to old defaults) is my preference at the moment.

Yes, naturally the config should be preserved. This is just a bug that is happening now. Thanks oli for supplying exact steps to reproduce. I will look into this now.

I have potentially found the root cause and have a fix in https://github.com/MariaDB/server/pull/1944, but I have not yet tested this. I will do that probably in the weekend.