Package managers should export a recovery state, not just a shopping list

I maintain several self-hosted systems, and I keep running into the gap between “these packages were installed” and “this machine can be rebuilt.” A selection export is useful, but it does not preserve the exact repositories, versions, signatures or configuration changes that made the system work. It certainly does not guarantee the dependency closure or provide the package artifacts when an upstream repository disappears, metadata changes, or a signing key is rotated.

Nix and Guix address much of this, while containers and distro snapshots cover other parts. I’m not arguing that every distribution should become NixOS. But mainstream package managers could expose a simple, user-owned recovery bundle by default: repository definitions, trust material, package identities or cached artifacts, relevant configuration, and enough dependency state to rebuild offline. I’m wary of recovery plans that quietly depend on a vendor or cloud still being available. Has anyone here actually rebuilt a machine from their recorded state rather than merely reinstalling from memory?

The distinction is sound, but I’d avoid calling a package selection export useless. Debian’s selection state records intent; it simply is not an archive. The more interesting question is which parts should be normative: exact content hashes, repository snapshots, or merely enough metadata to locate artifacts. Those choices have different storage and maintenance costs.

Trust material needs especially careful handling. A recovery bundle that preserves old keys forever could make restoration easier while also normalizing stale trust. I’d want explicit validity periods, provenance, and a visible “this is historical recovery material” boundary rather than silently treating yesterday’s trust root as current.

This feels like a good local-first primitive: export a signed manifest plus a closure of artifacts, then let the owner move it to offline storage. The bundle should be inspectable without the original package manager service. Otherwise it is just another pointer to infrastructure someone else controls.

The usability trap is that most people will not curate a growing archive of every package forever. A default feature probably needs retention policies and a clear size estimate, or it will be disabled immediately. “Export recovery bundle” is much easier to understand than a dozen knobs about caches and snapshots.

We used to call this an installation medium. The fashionable difference is that now the medium is a manifest pointing at six services, three registries, and a credential nobody documented. I’m not opposed to better tooling; I’m opposed to pretending a URL is an archive.

There is a counterargument: package managers cannot preserve configuration they do not own, and “working system” includes data, secrets, hardware assumptions, and local edits. A bundle can define a useful boundary, but calling it complete would create dangerous confidence. I’d support a precise partial guarantee over a magical restore button.

For small servers, I’d take a boring tarball of packages, repository files, and checksums over adopting a new operating model. Nix is powerful, but migration has a cost. The mainstream option should optimize for the person who only discovers reproducibility matters after the internet is already unavailable.

User ownership should include the signing and verification story. If the bundle can be regenerated but not independently verified, it is only convenient, not trustworthy. I’d rather see a portable format that multiple tools can read than a distro-specific blob that becomes another dependency.

The operational test is simple: can someone unfamiliar with the original host use the bundle during an incident? If it requires remembering which repository was temporary or which config was hand-edited, the export has failed its human job. Documentation and a dry-run restore matter as much as the archive.

I have rebuilt machines from notes and package lists, and “rebuilt” is doing a lot of work there. The packages came back; the subtle version and configuration assumptions did not. I’d absolutely use a standard bundle, provided it had a deterministic verification command and did not phone home to assemble itself.