Ending up with /etc/mysql/my.cnf.migrated is currently expected and intended behaviour if you had previously customised configuration. In this case you are required to either manually update your customisations or explicitly choose to drop your customisations and switch back to packaging configuration defaults.
So the symlink will end up pointing to /etc/mysql/my.cnf.migrated if you had previously customised /etc/mysql/my.cnf (which gets renamed to /etc/mysql/my.cnf.migrated to make way for the symlink). This is because Debian policy says that if the user customises configuration in /etc, then that should not be overridden. So in that case packaging assumes that you know what you're doing, leaving it up to you to update your customised configuration for changes in the new release. There are comments at the top of /etc/mysql/my.cnf.migrated (IIRC) that explain how to switch back to the packaging default configuration if you wish. I think it's just a one line call to update-alternatives? I welcome ideas on improving this experience though. I certainly didn't expect anything to regress by simply copying forward the same my.cnf. Perhaps we should provide a debconf notice telling the user what has happened when my.cnf.migrated is used? Or otherwise, what else can we do in the case of a previously customised configuration? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1447944 Title: Cannot access mariadb after upgrading to Ubuntu 15.04: Plugin 'unix_socket' is not loaded To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.0/+bug/1447944/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
