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."

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 is payload-only by design, today​

build-tideforge-supported.yml says so in its own comment:

COSMIC is deliberately payload-only for now: a full staged install requires the remaining runtime closure, which is not all factory-built yet.

So COSMIC meets 1 of its 4 declared gates (mock-build), not the rpm-md-stage-install, greetd-login, or cosmic-session-smoke it claims.

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."