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@in.waw.pl 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