dnf5daemon-server: Add D-Bus API to cancel ongoing transaction

[mcrha]

Calling any larger operation can take its time. For example the system upgrade can download multiple gigabytes of data, which the user (on the client side) might want to cancel and repeat later. Cancelling the org.rpm.dnf.v0.Goal::do_transaction() call itself on the client side does not help, the daemon continues with its duty. I did not try what the daemon does when I'd close the session in the middle of the transaction run, but that would be against session reuse (#1653).

I did not find a cancel() method, which I'd expect on the org.rpm.dnf.v0.Goal interface. The only one I found is the org.rpm.dnf.v0.Offline::cancel(), but it's not for generic goals/transactions.

Could you add a D-Bus API to cancel an ongoing transaction/goal within an opened session, please?

[mcrha]

I just verified that even if I close the session the goal is still running on the daemon side (the daemon is emitting D-Bus signals for non-existent dnf5 session).

[ppisar]

I don't know the D-Bus API, but reading your description, I find counterintuitive that org.rpm.dnf.v0.Goal::do_transaction() involves downloading packages.

There should be a separate phase for downloading the packages and a separate phase for executing the RPM transaction. Providing a way for canceling the download phase, you request, is reasonable. However, cancelling the RPM transaction is probably impossible. It depends on whether librpm supports it. And provided the transaction involves scriptlets with side effects, I believe it's unreasonable to try cancelling a running RPM transaction.

[ppisar]

Regarding the daemon continuing in transaction after loosing a session, that's a feature.

[mcrha]

For gnome-software, the install/uninstall are done immediately, the update/upgrade are done offline.

I do not see a problem in the do_transaction as it is now, it's better than the split call you suggest. Not every transaction requires the download, thus why should I decide whether it's needed or not, or even how a caller should make a decision. The command line neither does that, you just run dnf update/dnf install ... and that's all.

I agree not every phase can be cancelled, but it's not my decision, but yours/rpm's what can and what cannot be cancelled. If the hypothetical new cancel method would fail as "it's too late to cancel now", then I'm perfectly fine with it.

[m-blaha]

I've quickly checked the daemon sources and cancelling the transaction during the download phase should be relatively easy to implement.