On 3/26/20 1:32 PM, Zbigniew Jędrzejewski-Szmek 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.
No worries, just as long as we keep the discussion in one place :)
devel works for me just fine.
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.
Note that rpm will nag about the inconsistency between what's on disk
and configuration until resolved one way or the other (the message could
suggest --rebuilddb as well), so this wouldn't be an invisible thing.
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
And which of these upgrade paths we actually "support", or maybe the
term here is "recommend" to the average user?
This is the single biggest reason I left it so open: I got lost in the
"maze of upgrade tools, all alike" years ago. There's not much point for
me in devising a fancy scheme if it doesn't match what is expected in
Fedora. Hence this conversation (which is good!)
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.
Right, requiring changes to previous versions is not okay. I seem to be
thinking our upgrade tooling had gotten fixed at some point to perform
the upgrade on the target distro packaging management stack as it would
really need to be, but guess that was just a dream.
- 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.
An interrupted database rebuild is harmless, has always been. Just as
long as the one-shot service only decommissions itself once successfully
completed, there's no damage done, there will always be the next reboot.
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.
The new database is built in another directory and only if that
completes successfully, the old directory is moved out of the way and
replaced with the new. So it's as atomic as it can be.
- Panu -
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
_______________________________________________
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
