RFE: More useful keepcache options

[genodeftest]

Current dnf version: dnf5-5.2.17.0-2.fc43.x86_64

The current options of keepcache are only:

• True =keep everything always and forever
  • This will lead to ever accumulating pile of packages in the cache
  • This is not practical for any use cases where a high level of automation is intended, as one needs to call dnf clean […] on a regular basis
• False =delete cache after every successful transaction
  • If I understand this correctly, this will in some scenarios delete the already downloaded updates without installing them¹
  • This is not practical for people who often up-/downgrade packages over a low bandwidth connection.
  • My main reason for keeping cache is that I want to be able to downgrade recently updated packages to the previous version in case the update broke things like NetworkManager that would be relatively cumbersome to fix otherwise.

Most people probably don't want any of those extremes. Wouldn't it make sense to modify the caching behavior instead to keep at most 2 versions of a package in cache? This way, there would always be a package to downgrade to for a while. Of course this will break at some point, but there are probably very few or no users who are interested in keeping all versions of all packages they ever had installed.

So how about adding two more useful options:

• 1: Keep one version (usually the currently installed version) of each package in cache
• 2: Keep the two latest version in cache, usually the latest version and the version it was updated from

---

¹ Example scenario:

1. You have automatic download of updates enabled, but keepcache=False (the default)
2. Your machine is downloading the updates
3. Before the updates get installed, the user manually executes any dnf transaction (install/uninstall/…)
4. At the end of the manual transaction, the updates downloaded in step 2. get deleted
5. Machine needs to download the updates again

[genodeftest]

Alternatively, it might make sense to limit the cache in size, so that after a transaction, the cache is reduced to e.g. 2GB, deleting the oldest packages first. This will have a similar effect than 2., but with a different deletion order: The packages updated most often will be easier to downgrade, while the packages that are rarely ever updated will not have an older version in cache. This may or may not be helpful than the options described above, depending on the use case. However, it would allow more deterministic behavior (limit disk size consumed by cache) and would be easier to configure gradually, if someone needs to (like limit to 1GB, 10GB, …)