Upgrade to 5.5.36-rel34.1-642.squeeze silently changes my.cnf, breaks startup if change reverted

Originally reported at http://www.mysqlperformanceblog.com/2014/03/17/percona-server-5-5-36-34-1-now-available/#comment-5462437

The upgrade to (at least) 5.5.36-rel34.1-642.squeeze invokes a preinst script in your deb package of percona-server-server-5.5 which runs this code silently:

# TODO fixing my.cnf, prepending params with invalid paths with #
if [ -f /etc/mysql/my.cnf ]; then
sed -i -e ‘/^[^#].*share\/mysql/s/^/#/’ /etc/mysql/my.cnf
fi

We were not prompted in typical Debian fashion about the change to this file during the upgrade.

The code above, commented out this value in our /etc/mysql/my.cnf:

language = /usr/share/mysql/english

The upgrade appears to rename /usr/share/mysql to /usr/share/percona-server and so I understand the purpose of the change.

Because this is silent, and that the change actually *fixes* the my.cnf, there is no indication of what has happened to the end user.

However, for anyone who might have a Puppet-managed my.cnf, as we do, this is disastrous. The next Puppet execution replaced the my.cnf with the original version and scheduled a refresh of the mysqld service. MySQL failed to start back up once the `language` value was back in the my.cnf. Comparing the change in Puppet's clientbucket was how I discovered that your package modified the my.cnf.

The issue was solved either by changing the value in the config, or (a quick fix for us rather than work out new logic in our my.cnf template for our mix of database servers running different versions), symlink /usr/share/mysql to the new directory /usr/share/percona-server and restart MySQL.

As a couple of recommendations:

1) Don't make this change silent. Why is the TODO there? Is there are better, more Debian way to diff the change and accept/be made aware of the modification. In 2014, direct silent modifications of a config file are probably risky, I can't be the only one to be templating my my.cnf in Puppet.

2) Mention this quite significant /usr/share/mysql rename in the release notes. Why was it not mentioned in http://www.mysqlperformanceblog.com/2014/03/17/percona-server-5-5-36-34-1-now-available ?

3) Perhaps maintain /usr/share/mysql as a symlink if you are going to move it, to avoid such surprises?

System was Debian 6.0.9, 64-bit, upgrading percona-server-server-5.5 and related packages from 5.5.35-rel33.0-611.squeeze to 5.5.36-rel34.1-642.squeeze

Let me know if I can provide any more information.