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:
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.
[...]
- 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.
Looking at the details of how to do this now.
The idea is to install a generic "rebuild rpmdb on boot" one-shot
service, which can be flagged for action by 'touch
/var/lib/rpm/.rebuilddb'. That would be done from rpm %posttrans when
the rpmdb default changes, basically:
'[ -f /var/lib/rpm/Packages ] && touch /var/lib/rpm/.rebuilddb'
Should it become necessary, the same mechanism can be used to convert
back. This will of course trigger some "extra" rebuilds for anybody
staying on BDB backend but I'd say that's a feature...
I'm thinking of something like this for
/usr/lib/systemd/rpmdb-rebuild.service:
---
[Unit]
Description=RPM database rebuild
ConditionPathExists=/var/lib/rpm/.rebuilddb
[Service]
Type=oneshot
ExecStart=/usr/bin/rpmdb --rebuilddb
ExecStartPost=rm -f /var/lib/rpm/.rebuilddb
[Install]
WantedBy=basic.target
---
This seems to do the trick in my local testing, but there are probably a
million details that could be tweaked and improved. The systemd service
ecosystem is bit overwhelming for the uninitiated, so crowdsourcing here:
This should be run quite early in the boot, before other daemons that
potentially access the rpmdb get started (abrt, dnfdaemon), basically
just as soon as /etc, /usr and /var are mounted. Is there something else
I should add, or something better to hook onto? Other finer details that
I'm missing?
It'll need a preset to enable by default if this ends up being the route
taken, but lets hear the feedback first before I go file the bug...
- Panu -
_______________________________________________
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
