Issue 245: status calls a module behind when only its repository moved
This commit is contained in:
+41
@@ -0,0 +1,41 @@
|
||||
---
|
||||
status: open
|
||||
opened: 2026-10-05
|
||||
located-in: []
|
||||
fixed-by:
|
||||
amended-design:
|
||||
---
|
||||
|
||||
# 245 — `status` calls a module behind when only its repository moved
|
||||
|
||||
## What was observed
|
||||
|
||||
2026-10-05. After three catalogue merges that changed 11 modules, `status` listed **69 modules
|
||||
behind their source**, each as `holds <older commit>, source has <newer commit>`, with the advice
|
||||
"`build --behind` builds them; `push --behind` sends them on".
|
||||
|
||||
Between the two commits, `git diff --name-only` shows changes under 11 module directories only. For
|
||||
58 of the 69 modules listed, for example a Bluetooth module, the container runtime's, the forge's,
|
||||
the package manager's and the bus's, the diff of the module's own path is empty. Their sources did
|
||||
not change; only the repository's commit did.
|
||||
|
||||
The merges' plans were right: they rebuilt the changed modules and those that depend on them, by
|
||||
tier. Only the report was wrong. An agent following the report's own advice ran `build --behind`,
|
||||
which rebuilt all 69. The rebuilt bus module was rolled out, and its container was replaced on the
|
||||
control node. Every node's runtime lost the bus for about a minute.
|
||||
|
||||
## Why it matters beyond this instance
|
||||
|
||||
"Behind" is the word a person and an agent act on, and `status` attaches a command to it. A module
|
||||
is held to a commit of its repository, so after any merge almost every module of that repository
|
||||
reads behind. The list then says nothing about what needs building: it hides the few modules that
|
||||
really are behind among the many that are not, and it invites a rebuild of everything, which is not
|
||||
a harmless act (above).
|
||||
|
||||
## Open questions
|
||||
|
||||
1. Should "behind" compare the module's own sources, its path and whatever its build reads, between
|
||||
the commit it was built from and the repository's head, the way a plan already decides what to
|
||||
rebuild? A module whose files did not change could then simply move its recorded commit forward.
|
||||
2. Should `build --behind` use the same comparison, so it can never rebuild an unchanged module?
|
||||
3. Should `status` show only the modules an open plan has not yet rebuilt?
|
||||
Reference in New Issue
Block a user