dnf5daemon: Session caching can be harmful

[mcrha]

When using only a single session a package install followed by the same package uninstall results into: rpm transaction failed with code 5 and the package is not uninstalled, while using a different session for the uninstall works fine.

The package flags are also affected by this, because starting a new session and removing the package and immediately after that using the same session to get the package attributes keeps the is_installed flag of the package on true, while using two different sessions provides accurate information to the dnf5daemon client.

I believe both things are closely related, thus I filled them as a single issue.

This is with dnf5-5.2.5.0-20240826005752.50.gb1f839cd

[m-blaha]

This issue prevents gnome software from re-using the same dnf5daemon session. Bumping priority.

[m-blaha]

Proposed PR #1678 which re-sets the goal automatically after the do_transaction() execution. Also adds a new D-Bus API call to reset the goal manually.

[m-blaha]

Now I'm thinking about the second part (the is_installed flag), this would require re-reading the system repo. Let me explore what options there are.

[mcrha]

Now I'm thinking about the second part (the is_installed flag), this would require re-reading the system repo.

I see these options here:

1. either the current session made the change (installed/uninstalled a set of packages), then it can just update its cache for the touched packages accordingly, without reading the whole system repo
2. another session made the change, then the steps from the 1. should be done for all the active sessions
3. something from the outside (like the command line) made a change, then you'd need to re-read the system repo. Having a D-Bus method for such forced refresh (similar, but not the same as rh-bug 2124511) would help too, though there are currently no signals about the "rpmdb changed" in the dnf5, thus it's harder to detect command line changes on the client side (see dnf4's context: Get RPM db path from RPM, with common fallbacks libdnf#1542).