Research: Gitea 1.27 Debian + RPM package registry feasibility #35

Closed
opened 2026-09-02 18:31:20 +00:00 by xavierk · 1 comment
Owner

Parent map: Fenris deb + rpm release plan

Question

Verify the Gitea 1.27.1 instance at git.bongbetic.com can serve as the deb + rpm distribution channel: publish path (API PUT per format), apt sources.list + dnf repo config users need, repo metadata signing support vs passthrough, multi-distro metadata (apt distributions/suites fields, rpm distro tags), package version retention, and whether packages can attach to releases. Deliver exact client-side setup commands.

Parent map: [Fenris deb + rpm release plan](https://git.bongbetic.com/xavierk/Fenris/issues/33) ## Question Verify the Gitea 1.27.1 instance at git.bongbetic.com can serve as the deb + rpm distribution channel: publish path (API PUT per format), apt sources.list + dnf repo config users need, repo metadata signing support vs passthrough, multi-distro metadata (apt distributions/suites fields, rpm distro tags), package version retention, and whether packages can attach to releases. Deliver exact client-side setup commands.
xavierk added this to the Wayfinder: Fenris deb + rpm release plan milestone 2026-09-02 18:31:20 +00:00
xavierk added the wayfinder:research label 2026-09-02 18:31:20 +00:00
xavierk added a new dependency 2026-09-02 18:34:06 +00:00
xavierk self-assigned this 2026-09-02 18:34:20 +00:00
Author
Owner

Verdict: feasible — git.bongbetic.com (Gitea 1.27.1) can serve as the deb+rpm channel.
Everything below was verified live with throwaway packages (deleted afterward; package list confirmed empty).

Full findings: branch research/gitea-registry → docs/research/gitea-package-registry.md
(https://git.bongbetic.com/xavierk/Fenris/src/branch/research/gitea-package-registry.md — pending merge)

  • Publish (verified 201):
    • deb: curl -u xavierk:$TOKEN --upload-file f.deb …/api/packages/xavierk/debian/pool/{distribution}/{component}/upload
    • rpm: curl … --upload-file f.rpm …/api/packages/xavierk/rpm/{group}/upload (group optional: el9, rocky/el9, …)
    • Duplicate name+version (same dist/component/arch or group) → 409; must delete-then-reupload.
  • Client setup (exact):
    • apt: fetch …/debian/repository.key → /etc/apt/keyrings/gitea-xavierk.asc, then deb [signed-by=…] https://git.bongbetic.com/api/packages/xavierk/debian {distribution} main in sources.list.d.
    • dnf: sudo dnf config-manager --add-repo https://git.bongbetic.com/api/packages/xavierk/rpm/el9.repo (generated .repo already sets gpgcheck=1 + gpgkey).
  • Signing: native, not passthrough. Gitea signs apt metadata (clearsigned InRelease) and rpm repomd.xml.asc with per-instance auto-generated PGP keys; both verified gpg --verify → Good signature. No bring-your-own-key option in 1.27.
  • Multi-distro: apt distributions/suites + components are free-form upload path segments (tested bookworm + noble simultaneously; each gets its own dists/ tree). RPM groups likewise (el9 tested) with independent repodata/.
  • Retention: all versions kept indefinitely by default. Cleanup rules (KeepCount/KeepPattern/RemoveDays/RemovePattern) exist but are web-UI only in 1.27.1 — no REST route.
  • Release attachment: NOT supported. No package↔release linkage in 1.27.1 (source-verified). Plan: publish to registry + link URLs in release notes; tarballs as plain release assets or generic registry.
  • Caveats: publish under an org if multi-maintainer; keep owner public for token-free consumer URLs (verified anonymous metadata fetch works).

All test packages deleted; instance left clean.

**Verdict: feasible — git.bongbetic.com (Gitea 1.27.1) can serve as the deb+rpm channel.** Everything below was verified live with throwaway packages (deleted afterward; package list confirmed empty). Full findings: branch `research/gitea-registry` → `docs/research/gitea-package-registry.md` (https://git.bongbetic.com/xavierk/Fenris/src/branch/research/gitea-package-registry.md — pending merge) - **Publish (verified 201):** - deb: `curl -u xavierk:$TOKEN --upload-file f.deb …/api/packages/xavierk/debian/pool/{distribution}/{component}/upload` - rpm: `curl … --upload-file f.rpm …/api/packages/xavierk/rpm/{group}/upload` (group optional: `el9`, `rocky/el9`, …) - Duplicate name+version (same dist/component/arch or group) → 409; must delete-then-reupload. - **Client setup (exact):** - apt: fetch `…/debian/repository.key` → `/etc/apt/keyrings/gitea-xavierk.asc`, then `deb [signed-by=…] https://git.bongbetic.com/api/packages/xavierk/debian {distribution} main` in sources.list.d. - dnf: `sudo dnf config-manager --add-repo https://git.bongbetic.com/api/packages/xavierk/rpm/el9.repo` (generated .repo already sets `gpgcheck=1` + gpgkey). - **Signing: native, not passthrough.** Gitea signs apt metadata (clearsigned `InRelease`) and rpm `repomd.xml.asc` with per-instance auto-generated PGP keys; both verified `gpg --verify` → Good signature. No bring-your-own-key option in 1.27. - **Multi-distro:** apt distributions/suites + components are free-form upload path segments (tested `bookworm` + `noble` simultaneously; each gets its own `dists/` tree). RPM groups likewise (`el9` tested) with independent `repodata/`. - **Retention:** all versions kept indefinitely by default. Cleanup rules (KeepCount/KeepPattern/RemoveDays/RemovePattern) exist but are **web-UI only in 1.27.1** — no REST route. - **Release attachment: NOT supported.** No package↔release linkage in 1.27.1 (source-verified). Plan: publish to registry + link URLs in release notes; tarballs as plain release assets or generic registry. - Caveats: publish under an org if multi-maintainer; keep owner public for token-free consumer URLs (verified anonymous metadata fetch works). All test packages deleted; instance left clean.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Reference: xavierk/Fenris#35