Package: mysql-common
Version: 5.6.25-2
Severity: serious
Tags: patch
mariadb-common introduced some fallback mode to create a
my.cnf -> mariadb.cnf symlink (and renames the original my.cnf to
my.cnf.old) in case the update-links script is not available.
This needs to be handled in mysql-common, because currently
upgrading mysql-common over mariadb-common in in stretch/sid results in
my.cnf.migrated being created that is actually mariadb.cnf instead of
my.conf.old
Since the issue is hard to describe in detail and with all pitfalls
without digging into it and testing it, I rather developed patches
that I tested in sid and stretch, to ensure sane upgrade paths.
The commit messages should explain all the problems involved ...
if you have more questions, just ask.
This cleanup code needs to go into mysql-common since it cannot be
enforced that mariadb-common is upgraded first (that package may be
deconfigured or in config-files-remaining state, leaving a messed up
my.cnf)
git://git.debian.org/users/anbe/tmp/mysql-5.6.git
Andreas Beckmann (6):
mysql-common.postinst: install my.cnf.fallback alternative after
rm_conffile my.cnf
mysql-common.preinst: revert mariadb-common my.cnf fallback symlink
mysql-common.preinst: recover from unmodfied mariadb.cnf as
my.cnf.migrated
mysql-common.postrm: delete my.cnf.{migrated,old} on purge
mysql-common.postrm: only remove alternatives created by our postinst
mysql-common: add Breaks: mariadb-common (<< 10.0.20-3~)
Andreas
PS: this should go along with mariadb-common dropping that piece of code
and adding a Depends: mysql-common (>= 5.6.25-3), I'm working on patches
for this, too.
PPS: The migration of my.cnf from conffile to alternatives otherwise
looks well thought and implemented. The lack of mariadb-common handling is
understandable since that "fallback mode" was implemented only recently
and after the my.cnf migration was designed.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
