Skip to main content

TIDEFORGE READINESS

Assessed 2026-07-27 against feat/universal-package-recipes (#115) with the fixes from #125 applied.

The bar, from README.md: Tideforge "must prove source, build, install, and runtime parity before it replaces any native EL10 GNOME packaging." The promotion contract in docs/PACKAGE_FACTORY.md is stricter still: every candidate must "build in the target buildroot, pass package tests, install from the staged repository, and complete a desktop/runtime smoke test where the package affects a session."

Addendum, 2026-09-02. The strategy question this note kept open is settled in docs/PACKAGE_FACTORY.md ("One contract, one build engine per target"): Tideforge stays the recipe renderer for the targets whose coverage is complete (COSMIC and Niri on EL10 and deb; the Niri/DMS stack on Tumbleweed and Arch), each engine builds in its own root, and the contract -- roots, gates, status board, promotion rule -- is what is shared. A BuildStream-style "build once, package at the end" was measured and rejected for anything compiled (experiments/tideforge-universal-intermediate.md). GNOME on Hummingbird is consumed from utah-packages rather than built (HUMMINGBIRD-TARGET.md §7-8); GNOME on DEB is its own measured chain (gnome51-deb.yaml), not a Tideforge rollout step. The runtime-gate table below is still the open work.

Verdict​

The switch as usually framed — "move TunaOS packaging to Tideforge" — is not available, and not because Tideforge is immature. For the EL10 GNOME stack that TunaOS actually ships, Tideforge is not a candidate at all: that queue is declared implementation: native-spec. There is nothing to switch.

What is available today is a partial switch of two specific stacks — COSMIC and niri — whose recipe coverage is complete. Even those cannot be promoted under the current contract, because the runtime gates the contract requires do not exist yet.

Parity dimensionStateEvidence
SourceProvenverify-tideforge-source.py runs per package in CI; every recipe pins URL + SHA-256
BuildProven (after #125)All 40 recipes render for every declared target, 0 failures
InstallPartial8 Clean-install jobs out of 40 recipes
RuntimeNot started0 of 12 declared gate types implemented

Recipe coverage per queue root​

40 recipes exist. Coverage of the roots each queue declares:

QueueTargetImplementationRootsHave recipeMissing
cosmicel10native-spec1414—
cosmicubuntutideforge-debian1414—
cosmicdebiantideforge-debian1414—
gnomeel10native-spec(build_order)—Tideforge not proposed
gnomeubuntutideforge-debian91glib2, gobject-introspection, gtk4, libadwaita, mutter, gnome-shell, gnome-session, gdm
gnomedebiantideforge-debian91(same 8)
kdeel10native-spec33—
kdearchtideforge-pkgbuild44—
niriel10native-spec99—
niriubuntutideforge-debian88—
niridebiantideforge-debian88—
niriopensuse-tumbleweedtideforge-rpm88—
niriarchtideforge-pkgbuild99—
xfceel10native-spec43xfce4-wayland
xfcefedoranative-spec32libxfce4ui
xfcedebiantideforge-debian32libxfce4ui
xfcearchnative-pkgbuild32libxfce4ui

The GNOME DEB row is the one to read twice. Both GNOME DEB queues nominate Tideforge and declare 9 roots, but only bazaar has a recipe. The eight missing ones are the entire GNOME platform stack — glib2 through gdm. That is not a gap to close incrementally; it is the hard part of the problem, untouched.

Declared gates vs. implemented gates​

Counted across all five queue manifests:

GateTimes declaredImplemented?
container-build12yes
rpm-md-stage-install7partial — 8 Clean-install jobs total
apt-stage-install7partial — same
greetd-login7no
mock-build5yes
niri-session-smoke5no
xfce-wayland-session-smoke4no
cosmic-session-smoke3no
gnome-session-smoke3no
pacman-stage-install3partial
plasma-session-smoke2no
selinux-enforcing1no

Every runtime/session gate is declared and none is implemented. The manifests describe a promotion contract that CI cannot currently evaluate. Until that changes, no Tideforge recipe is contract-legal for promotion regardless of how green the build matrix is.

For contrast, the native EL10 GNOME path does have runtime verification — build-gnome50-verify.yml boots a CentOS Stream 10 VM under Lima, waits for GDM, checks that gnome-shell survives without crash-looping, and scans the journal for crash signatures. That is the standard Tideforge has to meet, and it already exists as a worked example to copy.

COSMIC installs and smokes, but the full staged closure is still ahead​

cosmic-session's gate cell (unified factory, #430) installs the package into a clean container and runs its smoke contract -- start-cosmic and the wayland-sessions desktop file are present -- but the desktop still cannot be staged end-to-end: the remaining runtime closure (greetd-selinux, adw-gtk3-theme, and the nine cosmic siblings cosmic-session depends on) is not all factory-built yet.

So COSMIC meets its install/smoke gate per package, but not the full staged-desktop gates (rpm-md-stage-install, greetd-login, or cosmic-session-smoke on a complete session) that the desktop edition needs.

Other gaps found​

  • aarch64 is declared but never built. manifests/package-factory.yaml declares el10 architectures: [x86_64, aarch64] and the same for ubuntu/debian (amd64, arm64). Tideforge CI builds x86_64/amd64 only. Any promotion would ship a half-architecture repo.
  • niri on Arch does not build. ld.lld: undefined symbol: spa_format_parse_libspa_rs and six similar — a pipewire-rs/libspa version skew against current Arch pipewire. This is a genuine upstream build problem, not a packaging or renderer bug, and it is unresolved.
  • build_repositories was not honoured. The manifest declares el10 build_repositories: [crb, epel], but the rpm-payload job enabled only CRB — which is what caused 13 of the 18 build failures fixed in #125. Worth a validator: nothing currently checks that a workflow's buildroot matches the contract it claims to implement.
  1. Do not attempt to move GNOME/EL10 to Tideforge. It is native-spec by design and the README's own policy keeps it authoritative. Treat this as settled, not pending.
  2. Implement the session gates first, modelling them on build-gnome50-verify.yml's Lima+VNC approach. Start with greetd-login — it is the most-declared runtime gate (7×) and gates both COSMIC and niri.
  3. Then promote niri, not COSMIC. niri has full recipe coverage across four targets and the smallest runtime closure; COSMIC is blocked on a runtime closure that is not yet factory-built.
  4. Add aarch64 to the Tideforge matrix before any promotion, or narrow the declared architectures in the manifest to match reality.
  5. Treat GNOME-on-DEB as a separate project, not a Tideforge rollout step. Eight platform packages — glib2, gtk4, mutter, gnome-shell, gdm and friends — is a body of work comparable to the existing native EL10 effort.

What #125 does and does not prove​

#125 fixes all 18 Build Tideforge supported targets failures. That proves the build dimension across the covered recipes, and it removes the noise that was hiding the real readiness picture. It does not move source, install, or runtime readiness, because the gates that would test those are not implemented. A green matrix on #115 should be read as "the renderer works", not "Tideforge is ready to take over."