Research: OBS as alternative build + distribution route #36

New Issue

2026-09-02T18:31:21Z

xavierk commented

2026-09-02 18:31:21 +00:00

Parent map: Fenris deb + rpm release plan

Question

Evaluate openSUSE Open Build Service as the build + distribution route: deb build support quality, vendoring textual>=0.40 into the build via source services (offline sandbox), signing, publishing reach (software.o.o / community repos), account and maintenance cost, build latency. Compare against the Gitea registry on our 4-distro matrix (Debian 12, Ubuntu 22.04/24.04, Fedora 40+, x86_64). Recommend OBS or reject, with reasons.

Parent map: [Fenris deb + rpm release plan](https://git.bongbetic.com/xavierk/Fenris/issues/33) ## Question Evaluate openSUSE Open Build Service as the build + distribution route: deb build support quality, vendoring textual>=0.40 into the build via source services (offline sandbox), signing, publishing reach (software.o.o / community repos), account and maintenance cost, build latency. Compare against the Gitea registry on our 4-distro matrix (Debian 12, Ubuntu 22.04/24.04, Fedora 40+, x86_64). Recommend OBS or reject, with reasons.

xavierk added this to the Wayfinder: Fenris deb + rpm release plan milestone 2026-09-02 18:31:21 +00:00

xavierk added the wayfinder:research label 2026-09-02 18:31:21 +00:00

xavierk added a new dependency 2026-09-02 18:34:07 +00:00

#38 Grilling: Lock channel + toolchain

xavierk self-assigned this 2026-09-02 18:34:22 +00:00

xavierk commented

2026-09-02 18:42:45 +00:00

Verdict: reject OBS as the build + distribution route; ship via the self-hosted Gitea 1.27.1 registry.

Findings (full write-up on branch research/obs, file docs/research/obs-route.md):

deb build quality — real. OBS builds deb from debian.control/debian.rules/dsc via dpkg-buildpackage; all five matrix targets (Debian:12, Ubuntu:22.04/24.04, Fedora:40/41) exist as build roots (verified live, 2026-09-03). Quirk: rebuilds don't bump release unless DEBTRANSFORM-RELEASE.
Vendoring textual≥0.40 — OBS doesn't help. Build workers run in secure mode without network (User Guide §7.2, §29.3), so vendoring must happen before the build anyway. Source services are per-file fetchers (download_url, obs_scm); there is no pip-resolver service. Distro python3-textual is 0.1.13 on all three deb targets, so a committed vendored tree is unavoidable on every route — OBS just reproduces ADR-0004's lockfile with extra XML.
Signing — worse. OBS signs published repos with the instance's key, not ours. Gitea's Debian registry signs apt metadata with our instance key (repository.key, signed-by); rpm repodata unsigned either way.
Publishing reach — OBS's only real win (download.opensuse.org CDN + software.o.o pages). Caveats: branched projects unpublished by default; repo is live project state, no release pinning. Irrelevant for a four-distro matrix whose users follow our README.
Account/maintenance cost — strictly additive. New openSUSE account, osc + _service XML + OBS-side package VCS to keep in sync. The scmsync bridge does support self-hosted Gitea, but disables OBS workflows (_link merging, etc.).
Build latency — global shared queue (scheduler→dispatcher→commons workers, fairness only, no SLA) vs. deterministic local build + one authenticated PUT per artefact to the Gitea registry.

Net: OBS adds account, workflow, and commons-queue dependencies to the release path while forcing the identical vendoring work — its reach advantage doesn't apply to this project. Revisit trigger: wanting software.o.o one-click installs, more architectures, or many more distros; the deb publishing quality is verified live and the SCM bridge would work with our Gitea.

Branch: research/obs — docs/research/obs-route.md (commit 8bcb1fe, not pushed).

**Verdict: reject OBS as the build + distribution route; ship via the self-hosted Gitea 1.27.1 registry.** Findings (full write-up on branch `research/obs`, file `docs/research/obs-route.md`): - **deb build quality — real.** OBS builds deb from `debian.control`/`debian.rules`/dsc via `dpkg-buildpackage`; all five matrix targets (`Debian:12`, `Ubuntu:22.04/24.04`, `Fedora:40/41`) exist as build roots (verified live, 2026-09-03). Quirk: rebuilds don't bump release unless `DEBTRANSFORM-RELEASE`. - **Vendoring textual≥0.40 — OBS doesn't help.** Build workers run in secure mode **without network** (User Guide §7.2, §29.3), so vendoring must happen before the build anyway. Source services are per-file fetchers (`download_url`, `obs_scm`); there is no pip-resolver service. Distro `python3-textual` is 0.1.13 on all three deb targets, so a committed vendored tree is unavoidable on **every** route — OBS just reproduces ADR-0004's lockfile with extra XML. - **Signing — worse.** OBS signs published repos with the instance's key, not ours. Gitea's Debian registry signs apt metadata with **our** instance key (`repository.key`, `signed-by`); rpm repodata unsigned either way. - **Publishing reach — OBS's only real win** (download.opensuse.org CDN + software.o.o pages). Caveats: branched projects unpublished by default; repo is live project state, no release pinning. Irrelevant for a four-distro matrix whose users follow our README. - **Account/maintenance cost — strictly additive.** New openSUSE account, `osc` + `_service` XML + OBS-side package VCS to keep in sync. The `scmsync` bridge does support self-hosted Gitea, but disables OBS workflows (`_link` merging, etc.). - **Build latency —** global shared queue (scheduler→dispatcher→commons workers, fairness only, no SLA) vs. deterministic local build + one authenticated `PUT` per artefact to the Gitea registry. Net: OBS adds account, workflow, and commons-queue dependencies to the release path while forcing the identical vendoring work — its reach advantage doesn't apply to this project. Revisit trigger: wanting software.o.o one-click installs, more architectures, or many more distros; the deb publishing quality is verified live and the SCM bridge would work with our Gitea. Branch: `research/obs` — `docs/research/obs-route.md` (commit 8bcb1fe, not pushed).

xavierk closed this issue

2026-09-02 18:42:46 +00:00

~~xavierk referenced this issue 2026-09-02 18:43:43 +00:00~~

Fenris deb + rpm release plan #33

xavierk referenced this issue

2026-09-02 19:46:14 +00:00

Grilling: Lock channel + toolchain #38

xavierk referenced this issue

2026-09-02 19:53:02 +00:00

Fenris deb + rpm release plan #33

xavierk referenced this issue

2026-09-02 20:14:58 +00:00