Files
hq/04-ISSUES/001-failed-package-install-reports-success/00-report.md
T
jschoubben 333356cff3 Order the records the way the system is learned
Jochen asked whether the order made sense. It did not -- it followed when
things happened to be decided, which after consolidation is fictional anyway
since record 5 alone folds decisions taken across a week.

Concretely wrong before: the domain statement sat at 8, after five engineering
rules; the constitution was scattered across 5, 12 and 17; the tiers landed at
15, 16, 21 and 22 with process records in between.

Now it walks: what the mesh is (1-3), its tiers from the bottom up (4-8), what
runs on them and how it gets there (9-10), how it is built (11-16), how it is
checked (17-18), how we work (19-23).

Two things made this safe rather than free. It is a permutation, not a
compaction, so the renames go through temporary names -- otherwise two files
want one slot and one is lost. And the reference rewrite is a single
simultaneous pass, because almost every number moved into a slot another number
was vacating; replacing one at a time would have cascaded and pointed things at
the wrong record while still resolving.

Verified: 284 [ADR NNNN](path) links across the repository, all with matching
text and target.

The ordering principle is now stated in 19 rather than left implicit -- the
repository already said "the numbering is the flow" about its folders, and
there was no reason for the records to be the exception.
2026-08-28 23:30:42 +02:00

1.5 KiB

status, opened, located-in, fixed-by, amended-design
status opened located-in fixed-by amended-design
open 2026-08-22

001 — A failed package install does not fail the job

Symptom

A module declared a package. The install produced, from every mirror:

error: failed retrieving file … 404

followed by:

-> error installing repo packages

The prepare job then reported success. The package is absent; the pipeline is green.

Why this matters more than one missing package

The first thing the lab work asked the mesh to install demonstrated the exact fault the lab exists to catch — a step that failed, reported success, and left the next step to run against state that was never produced.

It is also a direct violation of a decision already taken and recorded: ADR 0010 says a step that fails must fail the job. That record notes the rule is applied instance by instance and enforced by no mechanism. This is an instance where it was never applied.

Evidence

  • Observed 2026-08-22 while declaring the virtualisation package required by ADR 0016.
  • A fix is written and open as a pull request, unmerged since 2026-08-20.

Open questions

  • Why is the failure swallowed — is the exit status discarded, or never checked?
  • Is this specific to package installation, or does the surrounding stage swallow every non-zero exit?
  • The fix has been open for two days. What is the review path for a change of this class?