[debian-mysql] Bug#792080: mysql-common: needs to handle upgrades from mariadb-common that creates my.cnf -> mariadb.cnf symlink

[Andreas Beckmann]

On 2015-07-14 18:33, Robie Basak wrote:
> Hi Andreas,
> 
> On Sat, Jul 11, 2015 at 03:29:02AM +0200, Andreas Beckmann wrote:
>> 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.
> 
> Thank you for looking at this! I hadn't quite got round to it since I
> ended up focusing on the piuparts logger thing on my last pass over the
> MySQL packaging.

And many thanks again for digging into this!

> These all look fine to me,

I pushed another one to deregister the my.cnf.fallback alternative on
removal, otherwise purge gets noisy about the dangling link.

> but I presume depend on mariadb uploading a
> 10.0.20-3 with corresponding changes? I'm happy to commit this to git
> and get an upload (I'm DM now but I don't think I'm in the keyring yet)

If your regular sponsor is unavailable, I can help with uploading :-)

> but I guess we should coordinate with Otto for a corresponding mariadb
> upload?

I have just posted the mariadb changes to #787533.

In my tests with piuparts the upgrade paths now looks fine. Only people
that track sid and use mariadb, i.e. that had upgraded to mysql-common
5.6.25-2, may end up with an unneccessary my.cnf.migrated (could be the
pristine my.cnf from before the switch). It would be quite easy to
detect this as well, we would just need a (list of) md5sums of the old
pristine my.cnf to compare against.

Regarding myriadb - hmm, I make the typo quite often :-) - ...
I would even allow mariadb-10.0 10.0.20-2 to migrate to testing first,
but as long as it FTBFS on powerpc this is not going to happen ...
Any update to mariadb-10.0 in sid that does not include my changes would
require a corresponding version bump in the Breaks in mysql-common.

Will we have to adjust the versioning of the Breaks/Depends somehow to
also cover Ubuntu properly?


And now we are moving slightly offtopic in this bug:

* Have you considered building mysql-common from a separate source
package? Because since it is a required part for all mysql compatible
stuff it shouldn't be blocked by being bundled to a specific
implementation that is temporarily not being "ready for migration"

* What are your plans for the mysql-5.5 -> 5.6 switch? Is mysql-5.5
planned to be made installable again or is it just going to be removed?
Are there any packages (outside src:mysql-5.5) depending on the
versioned *-5.5 package names?

Andreas