Catch a package that has fallen behind Arch - #179
Open
omarchybot wants to merge 3 commits into
Open
Conversation
Ordering [omarchy] above core, extra and multilib turns staleness from dead weight into a downgrade. pacman stops at the first repository carrying a name and never compares versions across the rest, so an Omarchy build older than Arch's is not merely ignored: -Syu stops offering the newer official package, and the -Syyuu in omarchy-refresh-pacman actively downgrades to ours. intel-lpmd, pinta and umu-launcher had already drifted three months behind without anyone noticing, which is the argument for a check rather than a convention. It is written to run in an Arch container so the comparison is the one users get: Arch's own repositories for what it ships, and vercmp for which of the two builds pacman calls newer. Two things it deliberately refuses to do quietly. A repository that lists nothing is treated as a hole in the check rather than an empty repository, since multilib is disabled in the stock Arch image and multilib is where umu-launcher was hiding. And a PKGBUILD it cannot read is reported rather than skipped: 1password, 1password-beta and localsend read CARCH or SRCDEST at the top level, so they die under set -u and would have dropped out of the check unnoticed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
On pull requests touching pkgbuilds, because that is when a package older than Arch's would be introduced, and daily as well, because the other way this breaks is Arch moving while nothing here changes -- and nothing in a pull request can catch that. The container enables multilib before syncing. It is disabled in the stock Arch image, and multilib is where umu-launcher sat behind an older Omarchy build for three months, so a check that skipped it would have missed the case that motivated it. Only the scheduled run notifies Basecamp: a pull request already reports its own failure, while Arch pulling ahead happens with nobody watching. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A review found three ways the check reported success without having compared what it claimed, which is worse than not having it: a green run is read as "no package is behind Arch". An empty or mis-mounted pkgbuilds tree left every counter at zero and printed "none behind". It now fails when nothing was examined, and the success line names how many packages and how many package names it actually compared, so a pass can be audited rather than trusted. A PKGBUILD that calls exit at the top level ended its subshell successfully without ever naming a package, and was skipped in silence -- a pkgname=pinta pkgver=1.0 that reaches extra's 3.1.2 unnoticed. Sourcing now decides on the source status and on empty output rather than on whichever variables survived, so a PKGBUILD that fails partway is reported instead of compared against a stale pkgver it left behind. Listing a repository no longer swallows failure with || true. A listing that failed after emitting rows kept the partial result and checked part of the repository while reporting success. Two corrections to what the check believes. [core] stays above [omarchy] in the ordering this guards, so a name Arch ships from core is unreachable here rather than shadowed: it is reported and no longer fails the run, which it would have as a false positive. And the check reads PKGBUILDs, which says nothing about what the mirror currently serves -- that gap is now stated at the top of the file rather than implied away. The workflow runs the check as an unprivileged user, because it sources every PKGBUILD and a pull request could otherwise replace vercmp in the container and have its own comparison come back equal. Verified: as that user, writes to /usr/bin/vercmp are denied and both mounts are read-only. It also runs when helpers/ changes, since package_dirs lives there and enumerating nothing is the failure that matters, and it only announces a stale package when the check itself failed rather than on any Docker or mirror error. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <codex@openai.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ordering
[omarchy]above[extra]and[multilib]makes staleness a downgrade rather than dead weight. pacman stops at the first repository carrying a name and never compares versions across the rest:pacman -S <pkg>pacman -Syupacman -Syyuuomarchy-refresh-pacmanrunsintel-lpmd,pintaandumu-launchersat three months behind Arch with nothing reporting it, which is why this is a check rather than a convention.bin/check-shadowedcompares everypkgnamehere against Arch's repositories withvercmp, pacman's own comparator, so the verdict is the one users' machines reach.[core]keeps its place above[omarchy], so a name Arch ships from core is unreachable here rather than shadowed: reported, and not a failure.A green run gets read as "nothing is behind Arch", so two things never pass quietly:
umu-launcherhides.exitat the top level names no package at all; one that fails partway leaves whichever variables already ran, including a stalepkgver. Sourcing decides on the source status and on empty output, never on the surviving variables. The variables makepkg exports are supplied, since1password,1password-betaandlocalsendreadCARCHorSRCDESTat the top level and would otherwise drop out underset -u.The success line names what it compared —
Checked 112 package(s) (135 names) against extra multilib— so a pass can be audited instead of trusted, and examining nothing is a failure rather than a clean result.It runs on pull requests touching
pkgbuilds/orhelpers/, sincepackage_dirslives in helpers and enumerating nothing is the failure that matters, and daily, since Arch moves while nothing here changes. It runs as an unprivileged user because it sources every PKGBUILD, and one able to write/usr/bin/vercmpin the container would decide its own verdict. Basecamp hears about it only when the check itself failed, rather than on any Docker or mirror error.This reads PKGBUILDs, which is what a pull request changes, and says nothing about what the mirror currently serves. #180 covers that.
🤖 Generated by Opus 5 in Claude Code. Reviewed by Codex XHigh.