Please consider adding "complete-transaction" support to DNF5

[hedayat]

The issue is extensively discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=1091702

Currently, in DNF4, if a transactions fails in the middle (e.g. system crash or power outage or DNF being killed), you should manually cleanup and put the system in a usable state, which can be both complex and fragile. Yum had a complete-transaction feature which could continue an interrupted transaction, which would be very helpful. Is there any plan to add such a feature to DNF5?

[ppisar]

There is a plan to support rolling back and replaying a history (issue #1224), similarly what DNF4 had. Currently there is no plan to implement "yum complete-transaction". The arguments are the same as in the quoted DNF4 bug.

[hedayat]

I hope it will be reconsidered, since AFAIK (and up to my last experience of the issue), all the suggested methods using dnf are dangerous and likely remove too much packages. I've always resorted to manually removing duplicates using rpm -e --nodeps ... so that I won't end up with a broken system. If it is acceptable, then OK :( Although, it is certainly out of rich of ordinary users and they need expert's help to properly recover the system after an interrupted DNF install/upgrade command. Otherwise, they can either end up with a broken system due to missing required packages, or they'll reinstall the OS.

And at least in DNF4, rolling back or replying the history doesn't work in these situations.

[j-mracek]

I am suggesting that dnf5 history redo should be implemented by a way that will resolve this use-case. I don't see any benefit in redo implementation that has very limited usage.

I would like to say that with history transaction operation we should focus more on use cases then in theory. Why people run redo.

I see two options

1. I delete something on filesystem - but for this case reinstall is a better option
2. Transaction finished with a fail (due to interruption) and I want to complete it. Note: In many cases this cannot be performed automatically due to random issues, but we can improve the situation

I also believe that additional use case for complete-transaction was store transaction and replay it later or on another system. For this use case we develop store and replay operation (development in progress).

[kontura]

I have tested the redo command in dnf4 for this use case and it already somewhat works. It is able to complete the interrupted transaction when it comes to rpms. So it correctly removes/installs/upgrades/downgrades..

There is a problem that for the rpm operations that happen before the interrupt the reasons are not set. Though the same happens when the user recovers manually with rpm so using redo should have the same result but easier.

When working on dnf5 redo I tried to improve it: https://github.com/rpm-software-management/dnf5/pull/1595 redo now changes the reasons so the interrupted transaction should be completed correctly.

Of course any additional testing would be greatly appreciated.