Fenris/docs/research/obs-route.md

Research: OBS as an alternative build + distribution route

Resolves Research: OBS as alternative build + distribution route on the Wayfinder map.

• Date: 2026-09-03
• Verdict: Reject OBS now; ship via the self-hosted Gitea 1.27.1 registry (deb + rpm), and revisit OBS only if publishing reach becomes a goal.

Question

Evaluate openSUSE Open Build Service (OBS) as the build + distribution route — deb build quality, vendoring textual>=0.40 via source services (offline sandbox), signing, publishing reach, account/maintenance cost, build latency — against the Gitea registry on our matrix: Debian 12, Ubuntu 22.04/24.04, Fedora 40+, x86_64.

Findings

1. deb build support quality — real, with quirks

• OBS builds deb via the classic recipe trio: debian.control, debian.rules, PACKAGE.dsc (OBS User Guide §2.3 "Debian: Dsc"). The build phase runs dpkg-buildpackage on Debian-based distributions (§25.1.3 "Package Build"); Debian build environments can alternatively use the debootstrap build engine (§"Configuration File Syntax", BuildEngine).
• Quirk: release numbers are not auto-incremented across rebuilds unless the dsc carries DEBTRANSFORM-RELEASE (§2.3) — a packaging decision we'd own either way.
• Upstream build deps are available: dh-virtualenv and dh-python exist in Debian 12 (packages.debian.org, checked 2026-09-03), so the ADR-0004 venv/lockfile design maps onto an OBS dsc without patching the build root.
• All five matrix targets exist as public OBS build roots: Debian:12, Ubuntu:22.04, Ubuntu:24.04, Fedora:40, Fedora:41 — each project _meta answered HTTP 200 on build.opensuse.org (checked 2026-09-03).
• Live proof of deb publishing quality: isv:ownCloud:desktop/Debian_10 on download.opensuse.org serves a proper Debian archive (Release, Release.gpg, InRelease all HTTP 200, checked 2026-09-03).

2. Vendoring textual≥0.40 — the offline sandbox forces the same work we already planned

• The build environment has no network: "services requiring external network access are likely to fail in [buildtime] mode, because such access is not available if the build workers are running in secure mode (as is always the case at https://build.opensuse.org)" (User Guide §7.2, "Modes of Source Services"); Dockerfile builds likewise run "in a safe build environment without network access" (§29.3).
• Vendoring must therefore happen before the build, via source services that run server-side on commit (default/trylocal modes, §7.2) or via files committed to the package. The standard services are per-file fetchers — download_url (§22.1.3), download_files, obs_scm/tar/set_version (§8 SCM integration) — there is no "pip resolve" service, so a pinned dependency tree like Fenris's means either N download_url entries mirroring the committed lockfile, or simply committing the vendored wheel/sdist tree.
• Conclusion: OBS does not remove the vendoring step; it reproduces ADR-0004's committed-lockfile design with extra XML. Since distro python3-textual is 0.1.13 on Debian 12, Ubuntu 22.04 and 24.04 (packages.debian.org / packages.ubuntu.com, checked 2026-09-03) — far below the >=0.40 floor — vendoring is unavoidable on any route.

3. Signing — OBS key, not ours; Gitea deb repo is our key

• OBS signs published repositories with the instance's key: one signer per partition "calls an external tool to execute the signing" (User Guide §23 "OBS Architecture", Signer); consumers accept the OBS repo key ("When prompted, accept the GPG key of the download repository", §1.10). A build.opensuse.org user cannot upload a personal signing key. Trust therefore flows to openSUSE infra, and the signature says nothing about Fenris's maintainers.
• Gitea 1.27.1's Debian registry serves apt metadata signed with the Gitea instance's PGP key (repository.key endpoint, signed-by in sources.list — docs.gitea.com, "Debian Package Registry"), i.e. our host and our key. The RPM registry serves a .repo endpoint but documents no GPG signing of repodata; rpm-file signing stays our choice at build time.

4. Publishing reach — OBS wins reach; reach is not our bottleneck

• OBS publishes home-project results to https://download.opensuse.org/repositories/home:USER/<dist> (§1.10) and offers generated download pages on software.opensuse.org (§17.4). That is genuine CDN-class reach.
• Caveats from the same docs: branched projects are not published by default (§1.10), and the repo is a live view of the project state — no release artefact pinning; deleting the project or flag disables distribution.
• The Gitea route's reach is exactly git.bongbetic.com plus whatever the README says — adequate for a named four-distro matrix whose users follow our instructions, and it keeps the release artefact under versioned control on the same host as the source.

5. Account and maintenance cost — strictly additive

• Using build.opensuse.org requires an openSUSE account (single sign-on; the web UI's "Sign up!") and work happens in home:USERNAME plus permitted subprojects (§"Setting Up Your Home Project for the First Time"; §23 "OBS Concepts" on home projects).
• Day-to-day: osc + _service XML + dsc/spec recipes maintained in OBS's own package VCS, kept in sync with Fenris's git. The SCM bridge (scmsync) does support self-hosted Gitea ("We also support Self-Hosted instances from GitHub, GitLab and Gitea", §8.1.3; setup in §28.1.2 — build descriptions must live in the repo's top level), but it also disables OBS-side workflows (no _link merging, limited workflows, §28.1.1).
• No published quota/SLA for the public instance; capacity and availability are a shared commons. The Gitea route needs zero new accounts, zero new artefact formats beyond the two package recipes we must write anyway, and reuses the existing release host.

6. Build latency — shared queue vs. deterministic local

• OBS routes every commit through scheduler → dispatcher → shared workers; the dispatcher "tries to assign jobs fairly between the project repositories" using a per-repository load model (§23, Scheduler/Dispatcher). For our five tiny x86_64 jobs this is typically minutes, but there is no documented SLA and the queue is global — worst case is unbounded (estimate; the docs guarantee only fairness, not latency).
• The Gitea route builds wherever make runs and publishes with one authenticated PUT per artefact (docs.gitea.com: Debian PUT .../pool/{distribution}/{component}/upload; RPM PUT .../rpm/{group}/upload). Latency = build time, fully under our control.

Comparison on the 4-distro matrix

Axis	OBS (build.opensuse.org)	Gitea 1.27.1 registry
Debian 12 / Ubuntu 22.04/24.04 deb	dsc + dpkg-buildpackage; DEBTRANSFORM-RELEASE quirk	we build the same deb locally, upload via PUT
Fedora 40+ rpm	spec + rpmbuild in Fedora roots	same spec built locally, .repo grouping (fedora/40)
Vendoring textual≥0.40	offline sandbox forces committed vendored tree (no pip service)	same committed vendored tree (ADR-0004 lockfile)
Signing	OBS instance key (not ours)	deb repo signed with our key; rpm repodata unsigned
Reach	download.opensuse.org CDN + software.o.o pages	our domain only
Accounts/infra	new openSUSE account, osc workflow, commons SLA-free	zero new infra
Latency	global shared queue, minutes typical, no SLA	deterministic (local build)

Recommendation

Reject OBS as the build + distribution route for Fenris. The offline sandbox forces the exact vendoring work the Gitea route already requires, so OBS adds cost (account, osc/source-service maintenance, external commons in the release path, queue latency) without removing any; its one real advantage — CDN and software.o.o reach — does not matter for a hobby project whose four target distros are served by one signed apt repo and one rpm repo on the existing Gitea host, under our own key.

Revisit trigger: if Fenris later wants one-click installs via software.opensuse.org, architectures beyond x86_64, or many more distro targets — the deb publishing quality (verified live) and self-hosted-Gitea SCM bridge make OBS a viable amplifier then.

Sources

• OBS User Guide (openbuildservice.org/help/manuals/obs-user-guide/, PDF): §2.3 Debian: Dsc; §7 Using Source Services (offline buildtime services, modes); §8.1.3 Supported SCMs; §17.4 download pages; §22.1.3 download_url; §23 OBS Architecture (Scheduler/Dispatcher/Signer); §25.1.3 Package Build; §28.1 SCM bridge; §29.3 Dockerfile builds (no network); §1.10 Installing Packages from OBS; "Configuration File Syntax" (BuildEngine, Repotype: debian).
• Live checks (2026-09-03): Debian:12/Ubuntu:22.04/Ubuntu:24.04/Fedora:40/Fedora:41 project _meta on build.opensuse.org (all 200); isv:ownCloud:desktop/Debian_10 Release/Release.gpg/InRelease on download.opensuse.org (all 200).
• packages.debian.org / packages.ubuntu.com (2026-09-03): python3-textual 0.1.13 on bookworm, jammy, noble; dh-virtualenv, dh-python present in bookworm.
• docs.gitea.com, "Debian Package Registry" and "RPM Package Registry" (1.27 line): apt sources with signed-by + repository.key, PUT upload endpoints, .repo groups.