Ryan Tandy: > Fixing this for upgrades from jessie to stretch requires a jessie update > as well, to dump out the databases upon remove. > > The patches I intend to submit are attached. I would appreciate it a lot > if anyone reading this could take the time to review and try to point > out any edge cases I missed. > > The changes are intentionally minimal. Some refactoring will probably be > in order, but that can wait for buster. > > The intended paths are: > > - standard upgrades from jessie to stretch should not dump/reload the > databases needlessly > - remove-upgrade-install from jessie to stretch with the ppolicy schema > installed should succeed: the config should be dumped before remove so > that it can be updated and reloaded in postinst > - upgrades from current jessie to stretch should still work > - if preinst fails after dumping in prerm (for example because the > ppolicy check decides a manual update is required), and the upgrade is > retried, the second prerm should dump again and the updated data > should be used for the upgrade
Hi Ryan, Thanks for cooking up these patches. A quick review on my part found nothing and I am going to ask the SRMs if this approach is ok (usually we are not much for relying on people to upgrading to the latest point release before a major upgrade). Related: * Can we trivially document the steps so the user / admin can perform this manually (assuming they do not upgrade their stable version first)? - If so, then I will add that to the release notes. * The next point release is probably going to be later this month. The current (but not yet announced) dates means that the stable fix probably has to be uploaded before the end of the next weekend at the latest. Thanks, ~Niels
signature.asc
Description: OpenPGP digital signature
