You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 7d6ca7e
Browse filesBrowse the repository at this point in the historyBrowse files
convergence kept the declared list current and let everything else rot
On this laptop, right now: 13 outdated brew formulae, ten of them casks,
a stale org.gnome.Sdk runtime, and convergence running daily the whole
time. None of it was a bug in the sense of something not working. Both
syncs upgraded exactly what they were told to upgrade:
xargs -a "$declared" "$brew" upgrade
flatpak install ... --or-update <declared>
Scoping the upgrade to the declared list looked like the same restraint
that scopes *removal* to the declared list, and it is not the same thing
at all. Membership and currency are different questions and only the
first belongs to the declaration. Convergence decides what exists.
Nothing decided how old it was allowed to get.
That mattered more after `73771ab`. Taking back only what convergence
installed is what made it safe to ship a store, and shipping a store
makes "install an undeclared app" a path kuma actively encourages. The
combination shipped a way to install a browser that nothing on the
machine would ever update. It hadn't bitten yet only because there are
no undeclared flatpaks here yet.
So both upgrades lose their argument list. Bare `brew upgrade` also
takes casks, which kuma cannot otherwise see at all: `inspect.rs` reads
the Cellar, and every one of those ten fonts lives in the Caskroom, so
capture has never listed them and never will until that is fixed
separately. `flatpak update --system` covers undeclared apps and,
unlike the declared install, runtimes that no declared app happens to
demand.
This takes no authority it did not have. Updating is not installing:
membership still comes from the declaration, removal still only reaches
what convergence installed, and both ecosystems keep their own hold for
anyone who wants to stay put, `flatpak mask` and `brew pin`.
Ordering is load-bearing and the tests pin it. Both scripts run under
`set -euo pipefail`, so an upgrade placed before the state file is
written would, on one flaky-network run, abort with authority tracking
still describing the previous declaration and strand a removal until
some later run happened to have DNS. The flatpak prune moves after the
update so runtimes the update orphans go in the same pass.
The test needed hardening before it was worth anything, and sabotage is
what showed it: searching for the command and slicing from the hit hides
everything to its left, so a re-scoped `xargs -a "$declared" flatpak
update` read as unscoped, which is to say it passed exactly when the
property it guards had been undone. It matches whole lines now. Three
sabotages verified: re-scoping either upgrade, and pruning before the
update.
Docs say the rule plainly in concepts.md and both examples, since "being
undeclared costs reproducibility, never survival" was true and
incomplete. Also fixes four em-dashes that survived the repo-wide purge
in files written after it. 135 tests, shellcheck clean on both generated
scripts, fmt and clippy clean.
0 commit comments