You push a new build of a package to your internal RPM repository, but on a RHEL 9 client `dnf install` still offers yesterday's version. What are the likely causes, and how do you make dnf see the new build?

## dnf does not phone home on every command A package manager that fetched a full repository index for every `install` would be unusable, so dnf downloads each repository's metadata once and caches it under `/var/cache/dnf/`, in a directory named for the repository ID and architecture. Subsequent commands read that cache. The cache is only considered stale after `metadata_expire` has elapsed — 48 hours by default in `/etc/dnf/dnf.conf`, though individual `.repo` files routinely override it with something much shorter for fast-moving repositories. That design is why "I published it, the client can't see it" is a routine support ticket rather than a real fault. The client is behaving exactly as configured. ## Forcing the client to look again ```bash sudo dnf --refresh upgrade # expire all repo metadata for this run sudo dnf clean metadata # drop the cached indexes sudo dnf makecache # fetch them again now sudo dnf --setopt=internal-apps.metadata_expire=0 install myapp ``` `--refresh` is the everyday answer: it marks the metadata expired for that invocation, so dnf re-downloads before resolving. `dnf clean metadata` removes the cached indexes and leaves downloaded packages alone; `dnf clean packages` does the reverse; `dnf clean all` does both and is the sledgehammer people reach for out of habit. `dnf makecache` prefetches metadata without installing anything — on RHEL 9 the `dnf-makecache.timer` unit runs it periodically so that interactive commands feel fast, which is another reason the cache is often warm with slightly old content. `--setopt` deserves a mention beyond this problem: it overrides any dnf or per-repository configuration option for one run, written either as a global option (`--setopt=install_weak_deps=False`) or scoped to a repository as `<repoid>.<option>`. It is how you test a configuration change before you commit it to a file. ## Is the repository even enabled? Repositories are defined by `.repo` files in `/etc/yum.repos.d/`. A definition carries an ID in square brackets, a `name`, a location (`baseurl`, or `metalink`/`mirrorlist` for mirrored content), `enabled`, and the signature-checking settings `gpgcheck` and `gpgkey`. `dnf repolist` lists the enabled repositories; `dnf repolist --all` lists every configured one with its enabled/disabled state, which is the command that ends the argument. A repository with `enabled=0` is simply not consulted — its packages are invisible to search, install and upgrade — unless you turn it on for a single run with `--enablerepo=<repoid>` (and its mirror image, `--disablerepo=<repoid>`, temporarily takes one out). Note that `enabled` and `gpgcheck` are unrelated knobs: disabling a repository is not the same as skipping its signature verification, and confusing the two is a common stumble. Once you have a candidate, `dnf repoquery --repoid=internal-apps myapp` asks that specific repository what versions it is offering, which separates "the client cannot see it" from "the repository is not serving it". ## The server side An RPM repository is a directory of packages plus a `repodata/` index generated by `createrepo_c`. Copying a new RPM into the directory changes nothing that a client can observe: until `createrepo_c --update` regenerates the index, the published metadata still describes yesterday's package set. If the metadata timestamp on the server has not moved, stop debugging the client. The same reasoning applies to caching layers in between — a CDN or reverse proxy in front of the repository can serve a stale `repomd.xml` long after the origin was updated, and the symptom is identical. ## The order to work in Check the server's `repodata` timestamp, then the client's repository state with `dnf repolist --all`, then bust the client cache with `--refresh`. Doing it in that order means you find the cause rather than making the symptom disappear; `dnf clean all` as a first move often "fixes" it by accident and teaches you nothing about why it happened, which is the answer an interviewer is quietly listening for.