APT local package cache and Debian mirrors: stale metadata and install-time consistency

The contract in one sentence

An install operation may assume nothing about how closely /var/lib/apt/lists matches the mirror. APT resolves dependencies and picks versions purely from the local snapshot; the mirror is only contacted when a .deb actually has to be downloaded. Freshness is the operator's responsibility, not the toolchain's.

What happens when a cached version no longer exists upstream

The documented failure mode is a download-time error, not a resolution-time one. APT plans the install against the stale index, then the fetch of the superseded .deb fails with a Failed to fetch ... 404 Not Found, and apt-get install aborts. There is no fallback logic that silently substitutes a different version, and retry settings only mask transient network errors — they cannot fix a genuine 404 caused by stale metadata. The supported remedy is to run apt-get update and retry, which realigns the cache with what the mirror currently carries.

This matters on Debian 12 because official mirrors generally keep only the current version of a package per suite. Bookworm's churn is low, but security updates still replace files, so a cache even hours old can reference a removed .deb.

Does APT detect staleness on its own?

Only partially, and not in the way that would help here. The one built-in mechanism is the Valid-Until field in the repository's Release file: once the index is older than that, apt warns that the data is expired. That guards against replayed or very old metadata as a security measure — it does not detect that a specific version vanished from the mirror, and a cache can be well inside its Valid-Until window and still reference removed files. So no: an explicit refresh is the only supported remedy.

Recommended refresh cadence for automated installs

Don't think in terms of a cadence measured in hours; think in terms of job boundaries. The recommended pattern is to run apt-get update in the same job, immediately before any install or upgrade, so resolution and download work from one fresh snapshot:

apt-get update && apt-get install -y --no-install-recommends somepackage

This is the model unattended-upgrades follows — it refreshes lists before upgrading. Two practical notes:

• Update all configured sources together. Mixing lists refreshed at different times across sources can produce internally inconsistent resolution.
• In air-gapped or snapshot-mirror setups, consistency depends on your local mirror's snapshot policy instead; the same update-before-install rule applies, but staleness is bounded by how often the snapshot advances.

Verifying the behavior on your system

Check index freshness with ls -l /var/lib/apt/lists and inspect the Release file's Date and Valid-Until fields. To confirm the failure mode, install a package whose version was just superseded by a security update and observe the 404, then rerun apt-get update and see it succeed. Exact warning text and option names can vary with the APT version shipped in bookworm, so confirm specifics against the local apt-get(8) man page and /usr/share/doc/apt/.

Likely explanation vs. confirmed: the resolution-from-local-snapshot model and the 404 failure mode are long-established APT behavior; the exact Valid-Until enforcement details are the version-sensitive part worth checking on your target system.