[debian-mysql] Bug#787533: Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

On 2015-06-15 11:09, Robie Basak wrote:
> The new mysql-common replaces the /etc/mysql/my.cnf conffile with a
> non-conffile maintainer-script-manager symlink (via
> update-alternatives). It is in VCS, though I want to fix a separate bug
> before I upload to minimise the impact on users of unstable and testing
> who will transition from 5.5 to 5.6 as soon as I upload.

as I promised here is a review:

a few comments from just looking at the commit 61e2b53

* mysql-common.postinst:
  - why is the fallback alternative being installed before #DEBHELPER#?
    won't that confuse dpkg-maintscript-helper?
    at least comment on it, the explanation below is very nice

* mysql-common.postrm:
  - upon purge, delete /etc/mysql/my.cnf.migrated
  - do not use update-alternatives --remove-all, remove only the 
    alternatives (possibly) installed by this package (ordered lowest 
    to highest priority)
    update-alternatives --remove is a silent no-op if the alternative 
    does not exist
  - rmdir /etc/mysql should be the last step for purge, not the first


How does the migration work if the mariadb-common mishandling of my.cnf has been performed?

from mariadb-common.postinst:

  configure)
    # New packaging paradigm for my.cnf as of Dec-2014 for sharing mysql
    # variants in Ubuntu. If the new mysql-common package does not provide
    # the update-alternatives facility, fall back to creating a symlink
    if [ -f /usr/share/mysql-common/configure-symlinks ]
    then
      /usr/share/mysql-common/configure-symlinks install mariadb "/etc/mysql/mariadb.cnf"
    else
      # As configure can be called many times, don't re-create the symlink
      # if it is there already
      if [ ! -L /etc/mysql/my.cnf ]
      then
        echo "Notice: configure-symlinks trigger could not be called."
        echo "Creating /etc/mysql/my.cnf as a symlink that points to mariadb.cnf."
        mv -f /etc/mysql/my.cnf /etc/mysql/my.cnf.old
        ln -sf mariadb.cnf /etc/mysql/my.cnf
      fi
    fi
  ;;


how does dpkg-maintscript-helper rm_conffile cope with the conffile being replaced with a symlink to a different file?
I expect you want to use my.cnf.old as my.cnf.migrated if and only if it was modified
and you never want to use (a symlink to) mariadb.cnf as my.cnf.migrated

mysql-common needs to Breaks: mariadb-common (<< version-where-that-mess-was-removed-again~)
and mysql-common.preinst may have to undo this before #DEBHELPER#
(mariadb-common may have been removed but not purged before the new mysql-common gets installed)
(or it may have been purged as well ... probably leaving my.cnf.old

(note: the mariadb.cnf alternative for my.cnf will be reinstalled correctly 
once the fixed mariadb-common gets configured (and that happens after mysql-common got configured)


it should be easy to detect: 

  if [ -L /etc/mysql/my.cnf ] && [ "$(readlink /etc/mysql/my.cnf)" = "mariadb.cnf" ] ; then ...


The important part is that dpkg cleanly forgets everything about the old conffile my.cnf,
otherwise tools like debsums will spew errors since the remembered md5sum does not match


Andreas

PS: so far I didn't test anything, just looked at commits (and mariadb-common.postinst)