It's embarrassing that in this day and age rpm cannot restart an aborted
(crashed, power-cut etc) transaction at all. This requires depsolvers to try
and work around it, while they don't have the necessary details to do so
really. Rpm of course doesn't know where a package originally came from, but as
we basically require all packages to be present locally when we start a
transaction, we can assume the not yet processed ones should still be there
when restarting after a crash.
Rpm should to write a persistent record of the transaction before starting one,
and then update it as it goes. At the bare minimum this needs to track all the
elements and update their status as we proceed so we can pick up where we left
off on per-package level and the transaction id so we can mop up any leftovers
from the earlier run. There are of course a million pesky details like "out of
band" scriptlets like %pretrans and %posttrans that could/should be eventually
tracked, but learn to walk before trying to run.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2950
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
