Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
Right now our mariadb-server packages have a pre-upgrade hook that prevents a major version upgrade from happening unintendedly, forcing users to uninstall the package, and then re-install to get the higher version package installed and the upgrade performed.
The reasoning is that a binary upgrade is a one-way action and can't easily be reverted once data files have changed, as older major releases may not understand newer file format details.
The "uninstall then reinstall" workflow is cumbersome though, e.g. as other packages may depend on the mariadb-server package and get removed along with it.
So I'd like to suggest an additional alternative approach: have the pre-upgrade hook also check for a specific marker file, e.g. /var/lib/mysql/major-upgrade-OK, and if this exists and was created not-too-long ago (an hour? a day?), and if that exists: proceed with the major version upgrade anyway, then remove the file in the post-upgrade hook on successful upgrade.
That IMHO makes the upgrade intention even more obvious, and at the same time the process less cumbersome.
I think this check is meaningless and should be removed altogether.
For one, it's inconsistent. Debian packaging allows major upgrade just fine, only RPMs prevent it.
Also, given our repository structure (a separate RPM repository for every major release) an unintended major upgrade is unlikely.
The vendor check should be kept though, because upgrade from distribution RPMs to ours doesn't work in a general case; only the major version check should be dropped.
It was almost fixed once, in the scope of MDEV-9584, but instead of just allowing the major upgrade, the goal in that task was set too high, and it was never accomplished.