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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
