On 4/17/20 5:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 17, 2020 at 04:48:11PM +0300, Panu Matilainen wrote:
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...
Shouldn't this be a one-time thing instead?
E.g. '%triggerpostun rpm < n.n.n-n', where n.n.n-n is the first
version with the changed default?
Not really, because with a once in a lifetime opportunity there are too
many ways things can go wrong. Also, we need to be herding people away
from BDB with increasing intensity so even if we allow them to stay on
BDB in F33, they will need to switch over at a not-so-distant future
point, and that's not tied to rpm package versions anymore.
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
[Unit]
Description=RPM database rebuild
ConditionPathExists=/var/lib/rpm/.rebuilddb
DefaultDependencies=no
After=sysinit.target
Should we also add Requires=sysinit.target I don't think we want this
running on a boot where basics are failing...
Before=basic.target shutdown.target
Conflicts=shutdown.target
Hmm, what's with the shutdown.target This is not a service that will
remain active so shutdown doesn't seem relevant.
[Service]
Type=oneshot
ExecStart=rpmdb --rebuilddb
ExecStartPost=rm -f /var/lib/rpm/.rebuilddb
[Install]
WantedBy=basic.target
(Service units have default dependency on basic.target, so if this
is to be ordered before basic.target, it needs DefaultDependencies=no.)
I guess the question is rather, is running before basic.target actually
reasonable or even desireable? At the very least, we'd need to also add
RequiresMountsFor=/var /var/tmp
...because obviously /var needs to be there for this. And that makes me
wonder what else is missing that we'd need.
- Panu -
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...
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
