nordisk/holger

holger-znippy-rpm-repository — crate card

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

• One-line pitch: znippy-archive-backed RPM (yum/dnf) repository — serves the rpm-md repodata index and Packages/ .rpms.
• Does: RpmRepoZnippy implements RepositoryBackendTrait serving repodata/repomd.xml, repodata/primary.xml, and Packages/{pkg}…rpm. Native protocol (like conda/go): packages served straight from the archive and the rpm-md index synthesized from the .rpm files present — primary.xml lists each package (name/version/release/arch parsed from filename, plus byte length + real SHA256), repomd.xml references primary.xml by SHA256+size, so dnf can verify. Index served uncompressed (.xml href; dnf picks codec from extension) so no gzip dep. Path-passthrough wins for archives carrying authoritative upstream metadata; synthesis is the fallback. Uses RpmMetaRow from znippy-common views.
• Key deps: traits, znippy-common (incl. views::RpmMetaRow), sha2, 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-rpm. Epoch + rpm-md <format> fields are parsed natively from the served .rpm header tag table (the header module), with filename NEVRA 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: