DNF metadata_expire Configuration and Automated Cache Refresh Boundaries

Cache Expiration Behavior

DNF caches repository metadata under /var/cache/dnf with a configurable metadata_expire value that defaults to six hours for new metadata and thirty days for previously successful metadata. The setting controls when an automatic refresh is triggered, yet the exact interaction between the expire window, explicit dnf makecache calls, and repository-level overrides remains a decision point for administrators who need predictable refresh timing.

Permission and Automation Constraints

Modifying metadata_expire in /etc/dnf/dnf.conf or per-repository files in /etc/yum.repos.d/ requires root access, creating a permission boundary for teams that delegate package operations to non-root automation. Running dnf clean metadata or dnf clean all as root removes cached data that scheduled jobs may depend on, while setting metadata_expire=0 forces a full metadata download on every operation.

Open Questions

1. Does a per-repository metadata_expire override the global default for both the initial six-hour and subsequent thirty-day windows, or only for the first refresh after a clean?
2. When dnf makecache is invoked by a non-root user, which metadata timestamp is updated—the per-user cache or the system-wide cache—and how does that affect subsequent root operations?
3. Is there a documented mechanism to signal cache staleness to running automation without requiring a full dnf clean cycle?