search

rpm-software-management / dnf5

Next-generation RPM package management system
Other
240 stars 77 forks source link

dnf5daemon: Session caching can be harmful #1653

Open mcrha opened 3 weeks ago

mcrha commented 3 weeks ago

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 commented 2 weeks ago

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

m-blaha commented 1 week ago

Proposed PR https://github.com/rpm-software-management/dnf5/pull/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 commented 1 week ago

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 commented 1 week ago

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 https://github.com/rpm-software-management/libdnf/pull/1542).