Distinguish repository and global Ubuntu snapshot overrides

Bottom line: Trace the source of a snapshot selection before relying on a command-line override. Keep a repository’s fixed snapshot and the global default in separate rows of the package-operation plan.

Source fact: documented behavior

The How to use the Ubuntu snapshot service documentation is the primary reference.

The Ubuntu snapshot service selects historical archive content using a UTC snapshot identifier. When a repository is configured with a specific snapshot, the guide says APT always uses it and ignores a different command-line --snapshot choice for that repository. A global APT::Snapshot default can instead be overridden with the command-line --snapshot option.

What the source does not establish

This article concerns snapshot-selection precedence, not approval to install old packages or a guarantee of complete application reproducibility. It does not prescribe the documentation’s historical timestamps, package versions or release examples. Confirm the installed APT and release prerequisites separately, and retain security-update assessment as an independent requirement.

Applicability questions

• Which repositories have an explicit fixed snapshot?
• Is a global snapshot default configured?
• What timestamp does the proposed command intend to select?
• Which repository should answer each package query under that combination?

DSE recommendation: predict selection per repository

DSE recommends a repository-by-repository selection table before a historical package exercise. Record the repository identity, any fixed snapshot, the global default and the proposed command-line choice. Write the expected effective selection for each row instead of assigning one timestamp to the whole host by assumption.

Have the operating-system owner review the actual source definitions and global configuration through approved inspection. Keep the managed origin of each setting visible. Investigate a repository-level pin before repeating a command with a different timestamp, rather than treating the command line as proof of the effective source.

Choose a harmless package query for the initial exercise and preserve the current configuration. Keep package installation, downgrade, application acceptance and security treatment outside the scope until separately approved. An archive selection decision should not implicitly authorize deployment of a historical package set.

For a fleet workflow, identify which settings are shared and which are repository-specific exceptions. Require the reviewer to explain any host that intentionally differs. Store the intended timestamp and relevant configuration revision together so later investigation can reconstruct the source choice without relying on a command copied into a ticket.

Verification and evidence

Proposed verification: use a disposable supported Ubuntu environment and two approved historical timestamps. Prepare separate fixtures for a repository-level fixed selection and a global default, then supply the alternate command-line choice through the documented query workflow. Predict the effective selection before observing package-origin and version information.

Keep the queried package and repository set controlled, and change only one selection mechanism at a time. Retain the actual source definitions, sanitized invocation and query results. Do not install an old package merely to demonstrate precedence. Escalate unexpected selection behavior before using the procedure to construct an application environment or approve a maintenance change.

Official references

• How to use the Ubuntu snapshot service — Ubuntu Server.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.