Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caching local plugin repo data prevents use of locally stored packages when used in back to back updates #519

Closed
uxwalter opened this issue Jan 20, 2024 · 5 comments · May be fixed by #544
Assignees

Comments

@uxwalter
Copy link

uxwalter commented Jan 20, 2024

Pardon the convoluted title.

Expected behavior:

  1. dnf update downloads to be updated packages, local plugin maintains a copy of downloaded package, and downloaded packages are installed on host 0
  2. Subsequent "dnf update" on hosts 1-n, after step 1 will not download updated packages but instead use copies maintained by local plugin

Actual behavior:

  1. Same as step 1 above
  2. Subsequent "dnf update" on hosts 1-n, when done shortly (O(minutes)) after step 1 will download updated packages again because, presumably, of cached data in /var/cache/dnf/_dnf_local*

The fact that the local plugin relies on cached repo data and therefore ignoring just downloaded updates seems to defeat the purpose of the local plugin if used to update multiple hosts at or around the same time.
If the cache is allowed to expire, is explicitly ignored with dnf command line options, or if the cached data is explicitly deleted before subsequent updates (e.g., rm -fr /var/cache/dnf/_dnf_local*) then the local plugin behaves as expected.

@j-mracek
Copy link
Contributor

j-mracek commented Feb 8, 2024

Thank you very much for the report.

I am not sure about several details of your use case or I am not sure whether plugin was intended for your use case.

May I ask you for a reproducer?

If the problem is related to using outdated cache after step one, I would recommend to use --refresh option in step 2.

@j-mracek
Copy link
Contributor

j-mracek commented Feb 8, 2024

I've tested scenario with --refresh and it worked according to your expectations.

@j-mracek
Copy link
Contributor

There is an alternative workaround. Use --setopt=_dnf_local=metadata_expire=0 in step 2.

I am closing the issue because the reported use case (using local plugin to generate cache for multiple systems) is not supported by the plugin.

@uxwalter
Copy link
Author

Thanks for looking into it. I made a code change to read metadata_expire form local's .conf file and sets it without the need of command line options, if there's interest I craft a PR.

The usage model I was describing is the same as the one documented in Fedora Magazine which got me to this plugin in the first place.

@j-mracek
Copy link
Contributor

I believe that the default for the local repository is incorrect, therefore setting metadata_expire=0 as a default for _dnf_local should be OK even without local's .conf file. Please feel free to provide a patch.

rrevans added a commit to rrevans/dnf-plugins-core that referenced this issue Jun 24, 2024
rrevans added a commit to rrevans/dnf-plugins-core that referenced this issue Jun 24, 2024
Also make this option configurable

Fixes rpm-software-management#519

Signed-off-by: Robert Evans <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants