A module names its base, so the mesh can act on what it notices #38

Merged
jschoubben merged 1 commits from feat/a-module-names-its-base into main 2026-09-13 21:58:24 +00:00
Owner

Closes the half of issue 044 that was left open.

The mesh could already say which modules a base change had invalidated, and could do nothing about it: each recipe named one particular copy of the base by fingerprint, so rebuilding produced the old one until somebody edited that line by hand.

That turned out to be worse than inconvenient. A fingerprint names one copy of an image, and a copy exists on one mesh — so the three modules in the catalogue named a copy produced inside a throwaway lab and could not be built anywhere else at all. The line each of them replaced had the same fault, pointing at a copy from an even earlier lab. Nobody noticed because the only place they had ever been built was the place the copy existed.

A module names the module and artifact now, and the mesh answers with the copy it holds. A base the mesh has not built is refused before anything is built, naming which module has to exist first.

Checked on a bare machine: postgres with nothing supplied is refused and says to build mesh-tools first; mesh-tools is built; postgres is built against it and the image carries the compiled module, the toolkit, and the database client it provisions through.

Closes the half of issue 044 that was left open. The mesh could already say which modules a base change had invalidated, and could do nothing about it: each recipe named one particular copy of the base by fingerprint, so rebuilding produced the old one until somebody edited that line by hand. That turned out to be worse than inconvenient. A fingerprint names one copy of an image, and a copy exists on one mesh — so the three modules in the catalogue named a copy produced inside a throwaway lab and could not be built anywhere else at all. The line each of them replaced had the same fault, pointing at a copy from an even earlier lab. Nobody noticed because the only place they had ever been built was the place the copy existed. A module names the module and artifact now, and the mesh answers with the copy it holds. A base the mesh has not built is refused before anything is built, naming which module has to exist first. Checked on a bare machine: postgres with nothing supplied is refused and says to build mesh-tools first; mesh-tools is built; postgres is built against it and the image carries the compiled module, the toolkit, and the database client it provisions through.
jschoubben added 1 commit 2026-09-13 21:58:17 +00:00
The mesh could already say which modules a base change invalidated, and could
not do anything about it: each recipe named one particular copy of the base by
fingerprint, and rebuilding produced the old one. Worse, the copy each named
existed only inside a throwaway lab, so those three modules could not be built
anywhere at all — and the line each replaced had the same fault.
jschoubben merged commit aa35ba1594 into main 2026-09-13 21:58:24 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/hq#38