I update the Wiki page to state that the current contingency plan is a revert of the change by bumping 'mariadb' package epoch. I also added a note about the dependent packages that need rebuild. That is a single package (amarok); I tested the rebuild in COPR and discussed it with the 'amarok' package maintainer.
-- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, Nov 17, 2020 at 8:12 PM Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > > On Thu, Nov 05, 2020 at 02:06:37PM +0100, Michal Schorm wrote: > > On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini <decatho...@gmail.com> > > wrote: > > > On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton <bcot...@redhat.com> wrote: > > > > == Contingency Plan == > > > > > > > > Modules will provide the functional version of MariaDB 10.4, available > > > > to all users. > > > > * 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 > > instead. > > > > 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 > > new version. > > 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 > > go. > > > > 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. > > So, any progress on this? > > Zbyszek > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
