nordisk/holger

holger-znippy-deb-repository — crate card

Reverse-engineered (from source — verify, don't trust the name)

• One-line pitch: znippy-archive-backed Debian (APT) repository — serves Release + Packages indexes and pool/ .debs.
• Does: DebRepoZnippy implements RepositoryBackendTrait serving dists/{dist}/Release, dists/{dist}/{component}/binary-{arch}/Packages, and pool/…/{pkg}_{ver}_{arch}.deb. Native protocol (like conda/go): packages served straight from the archive, and the index synthesized from the .deb files present when the archive doesn't carry one — each Packages stanza from the pool filename plus archive byte length + a real SHA256 of served bytes; Release references each Packages by SHA256+size (so apt [trusted=yes] can verify). Path-passthrough wins when the archive already carries authoritative upstream metadata; synthesis is the fallback. Synthesized indexes cached (immutable archive) to avoid re-hashing the pool per request.
• Key deps: traits, znippy-common, sha2 (real SHA256), anyhow.
• Shape: lib, single lib.rs. Shared znippy-backend pattern + native index synthesis.
• Observed role in the workspace: Registered in server-lib as repository-znippy-deb. Control fields are parsed natively from the served .deb bytes (ar + control.tar.{,gz,xz,zst}, the control module), with filename-derivation only as a fallback.

Fill in (one line each — only the human knows these)

• Primary consumer(s):
• Why it exists (vs the obvious alternative):
• Hard constraint (airgap / no-C-deps / no-FFI / pure-Rust / etc.):
• Release cadence & independence (rides a parent? own repo someday?):
• Status (production / prototype / experimental / stubbed):
• Must-NOT-change invariant:
• Biggest known gap or TODO:
• Anything a newcomer would get wrong about it: