On Thu, Mar 26, 2020 at 07:38:33AM -0400, Neal Gompa wrote: > On Thu, Mar 26, 2020 at 7:33 AM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > On Thu, Mar 26, 2020 at 01:16:22PM +0200, Panu Matilainen wrote: > > > On 3/26/20 1:02 PM, Zbigniew Jędrzejewski-Szmek wrote: > > > >On Mon, Mar 16, 2020 at 11:22:47AM -0400, Ben Cotton wrote: > > > >>=== Upgrading === > > > >>* Ability to upgrade is not affected > > > >>* After upgrade completes, manual action (rpmdb --rebuilddb) will > > > >>probably be needed to convert to sqlite. Alternatively user can change > > > >>configuration to stay on BDB. > > > > > > > >Do I understand correctly: > > > >- without the manual step, users will remain on the old format > > > >- with the old format, in F33 everything will still work fine, but > > > > after upgrade to F34, the database will become read-only > > > > > > > >Why is an automatic 'rpmdb --rebuilddb' not part of upgrade plan? > > > > > > To repeat what I said in https://pagure.io/fesco/issue/2360: > > > > Hi, > > > > thanks for quick answer and sorry for double-posting. I started > > reading the fesco ticket, then the change page, then the discussion > > here, and forgot to read the rest of the comment on the ticket. > > I also posted there, but I think it's better to discuss here. > > I'll copy my post from there here, sorry for the mess. > > > > > I left it open on purpose (note the "probably" in there) as there > > > would be any number of ways to achieve the rebuild with varying > > > degrees of automation and opt-out opportunities, depending on what > > > is actually desireable for Fedora. > > > > > > One possibility could be adding a rebuild step to dnf system-upgrade > > > plugin, rebuilding the db after distro upgrades is not a bad idea > > > regardless of db format changes (at least BDB performance would > > > gradually degrade unless rebuilt every now and then). That would > > > leave people doing the (unspeakable) distro-sync upgrade to deal > > > with database format manually, which might be just the right balance > > > of freedom. Or not, I dunno. Other possibilities include planting a > > > one-shot service that does the db rebuild on the next reboot and > > > decommissions itself afterwards in the rpm package itself. Other > > > variations certainly exist. > > > > > > Suggestions welcome, just as long as you don't suggest rebuilding > > > from rpm %posttrans :) > > > > Right. I realize %posttrans is not a good idea. But *some* mechanism > > is necessary, because without that the change will mostly be a noop > > for most users. So I think this needs to be decided somehow. > > > > Quoting from the FESCo ticket: > > About the various implementation options: > > > > - in dnf system-upgrade: this does not cover normal 'dnf > > --releasever=33 upgrade' upgrades (as you mentioned earlier), but it > > also does not cover packagekit upgrades. It'd also create a > > previous-release-blocker(s) and previous-previous-release-blockers(s), > > since the changes would need to be deployed in F32 and F31. Also > > note that the last time when the upgrade plugins run code is in > > upgrade phase between two reboots, and the plugin is running > > pre-upgrade code. This code would then invoke post-upgrade rpm. It's > > certainly doable, but seems a bit funky. > > > > It could be a libdnf post-transaction plugin. That would apply to any > mechanism of system upgrade using libdnf, either through dnf or > PackageKit. That sounds interesting... > > - a one-shot service: this is easier to implement, it just needs to > > happen in one place. The hard part is making sure that the machine > > does not get reboot while the upgrade is happening. This is in > > particular a problem with VMs and containers. The rebuild should be > > wrapped with systemd-inhibit and other guards to make it hard to > > interrupt. > > Wouldn't the systemd-inhibit plugin automatically ensure that a > rebuild action would block sleep/poweroff? Unfortunately... not. From the man page: inhibitors "may be used to block or delay system sleep and shutdown requests from the user, as well as automatic idle handling of the OS." Explicit non-interactive privileged requests override inhibitors [1,2]. This has been discussed, and I think there's general sentiment that we should have an ability to inhibit "everything", but so far nobody has pushed for a solution. A solution could be proritized if it turns out to be required in Fedora. [1] https://github.com/systemd/systemd/issues/2680 [2] https://github.com/systemd/systemd/issues/6644 > > No matter how it wrapped, is the upgrade itself atomic? Having the new > > db built under a temporary file name and then atomically rename(2)d > > into place would be ideal. > > > > Since RPM 4.14, RPM creates a new directory, writes the database > content there, then renames the directory when it's done. Does it use renameat2(RENAME_EXCHANGE)? Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
