Edge is the channel the 4.0.2 RC ISOs point pacman at until the rc-channel
migration lands, but edge only carried omarchy 4.0.1 — older than the
installed 4.0.2rc1, so those installs never saw an upgrade. Bumping master's
pin lets the normal edge pipeline build and publish 4.0.2rc2, whose migration
repoints [omarchy] at the rc channel.
Stable is unaffected: pinned packages never build for stable
(package_builds_for_mirror), it only receives them via the rc->stable advance
at ship time.
(cherry picked from rc-branch pin commit 11767d6)
The rc channel's Arch base can sit anywhere between stable's snapshot and
edge's, so a package built against stable's libraries is not necessarily
correct for rc. Copying stable's fast-ring artifacts into rc therefore shipped
possibly-mislinked packages to RC testers. Fast-ring packages now build
natively for all three channels, each in its own image against its own base
mirror, and the stable release's replication step is gone.
That required separating 'may be built here' from 'whose version wins'. The
release pair is now marked "pinned": its version is set per release on the rc
branch, so it builds for rc only from that branch's worktree
(OMARCHY_RC_PINS=1, set by omarchy-release rc) — master's shipped pins can
never overwrite an in-flight RC, even though check-versions now discovers rc
work like it does for edge and stable.
A package's .omarchy/package.json may now pin where it lives with
"channels": [...]. With the key present the package builds in each listed
channel except stable (stable is only fed by promotion); without it, today's
defaults hold (build for edge; fast-ring also builds stable directly).
package_moves_to_channel() is the advance/promote eligibility rule: a member
of the destination channel that is not built there natively.
The release pair (omarchy, omarchy-settings) is edge+rc+stable — edge stays
during the client-migration overlap window and drops later. The dev pair is
pinned to edge only.
omarchy-settings-dev provides omarchy-settings (unversioned), so an
unversioned dependency let the dev package satisfy stable omarchy's
settings requirement, allowing a mixed dev/stable install. A versioned
dependency (omarchy-settings=${pkgver}) can only be satisfied by the
real settings package from the same pinned commit and forces the pair
to upgrade together. Verified: requesting only omarchy on a system with
the -dev pair installed replaces both with the stable pair.
Stable-track counterparts of the -dev packages. Source is pinned to a
single shared upstream commit with a real sha256 (pacman 7 validates
checksums on commit-pinned git sources), versioned per the attached-rcN
convention so vercmp orders rc1 < rc2 < final. Seeded at 4.0.0rc1 from
the quattro tip because no upstream 4.x tag exists yet and the packaging
requires the quattro tree (v3.8.x has no shell/ or etc/).
Both packages stay off the fast ring: RCs publish to edge only; stable
receives finals via bin/repo migrate.
Ryan Hughes