On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton <bcotton(a)redhat.com>
> == Contingency Plan ==
> Modules will provide the functional version of MariaDB 10.4, available to all
> * Contingency mechanism: Fedora Modules for 10.4 available
This is not a sufficient contingency plan. Leaving broken 10.5
non-modular packages in f34 is a non-starter.
Is there a realistic path to back out of the 10.5 update in rawhide /
F34 if there are problems?
It looks like the 10.4 -> 10.5 update requires database upgrades as
well, so would MariaDB 10.4 have problems with accessing databases
that have been migrated to 10.5?
In the worst case scenario, I would be forced to revert the change,
bump MariaDB 10.4 package epoch and release F34 with MariaDB 10.4
Database upgrades in general (this is not just about MariaDB or MySQL)
are very problematic.
Every sane DB upgrade *ever* should have a data backup prior and I
don't want, nor have any means to, solve the cases of corrupted DB
data which haven't got a backup.
What would be an issue however, if a significant number of users would
report the upgrade is problematic and they can't use the DB with the
The best thing both they and I can do is to file a BZ ticket (so we
are informed about it in the first place).
I will search the upstream JIRA ticket system for workarounds as a
part of the problem solving.
If any are found, I'd try to apply them or at least provide them to the users.
If the issues would be in place but no solution in sight, the revert
to MariaDB 10.4 in Rawhide (and F34 if already branched) is the way to
If you will agree to this contingency mechanism, I will add it to the
Self-Contained Change wiki page.
Otherwise I'd ask you for a suggestion of what you picture as
sufficient contingency mechanism.
Core Services - Databases Team