An artifact's system is checked and then nothing uses it #208
@@ -89,3 +89,9 @@ work on.
|
|||||||
two of them is a C library, not a kernel" — and a static Go binary has no C library. So one build would
|
two of them is a C library, not a kernel" — and a static Go binary has no C library. So one build would
|
||||||
in fact run on all three. The pin is then a policy (a host refuses a machine it was not built for)
|
in fact run on all three. The pin is then a policy (a host refuses a machine it was not built for)
|
||||||
rather than a necessity, which is a reasonable thing to keep and is worth knowing is a choice.
|
rather than a necessity, which is a reasonable thing to keep and is worth knowing is a choice.
|
||||||
|
|
||||||
|
**And a sharper one, asked as a question and worth its own record.** The artifact's system is validated
|
||||||
|
and then read by nothing: it does not reach the compiler, no machine is matched against it, and nothing
|
||||||
|
chooses between two artifacts by it. The host built here is x86-64 because the build machine is, not
|
||||||
|
because anything in the declaration said so — correct for this mesh by coincidence. That is
|
||||||
|
[issue 159](../159-an-artifacts-system-is-checked-and-then-ignored/00-report.md).
|
||||||
|
|||||||
@@ -0,0 +1,82 @@
|
|||||||
|
---
|
||||||
|
status: located
|
||||||
|
opened: 2026-09-30
|
||||||
|
located-in:
|
||||||
|
- mesh-controller internal/catalogue/build.go (System is validated and read by nothing else)
|
||||||
|
- mesh-controller internal/builder (the compile invocation names no target)
|
||||||
|
fixed-by:
|
||||||
|
amended-design:
|
||||||
|
---
|
||||||
|
|
||||||
|
# 159 — An artifact's system is checked, and then nothing uses it
|
||||||
|
|
||||||
|
## What was observed
|
||||||
|
|
||||||
|
Asked whether the host is built for more than one architecture, 2026-09-30, having just built it
|
||||||
|
through the new Go toolchain.
|
||||||
|
|
||||||
|
[ADR 0142](../../02-DECISIONS/0142-the-mesh-delivers-its-own-components-as-binaries.md) says an
|
||||||
|
artifact declares what it targets, and that one artifact per target is one build each. The manifest
|
||||||
|
layer enforces the first half strictly: a bundle in a language that compiles to a binary **must** name
|
||||||
|
a system, must name one of `alpine`, `android`, `arch`, and must not name one at all if its language is
|
||||||
|
interpreted. A manifest that gets any of that wrong is refused with a reason.
|
||||||
|
|
||||||
|
**The field is then read by nothing.** Every use of it in the control plane is in the function that
|
||||||
|
validates it. It does not reach the compiler, no machine is matched against it, and nothing chooses
|
||||||
|
between two artifacts by it.
|
||||||
|
|
||||||
|
So the compile runs with no target named and produces a binary for whatever the build machine happens
|
||||||
|
to be. The host, declared `system: arch` and built on this mesh's only build machine:
|
||||||
|
|
||||||
|
```
|
||||||
|
mesh-host: ELF 64-bit LSB executable, x86-64, statically linked, stripped
|
||||||
|
```
|
||||||
|
|
||||||
|
Correct for every machine in this mesh, which are all x86-64 Arch — and correct by coincidence rather
|
||||||
|
than by anything the declaration did.
|
||||||
|
|
||||||
|
## Why it matters
|
||||||
|
|
||||||
|
**A module declaring two systems would get two identical binaries.** Both would be published, both
|
||||||
|
pinned, both delivered, and the one sent to the machine it was not built for would fail at exec with a
|
||||||
|
message about a format — which is the shape ADR 0005's link-time pin exists to prevent, arriving
|
||||||
|
because the pin was never applied.
|
||||||
|
|
||||||
|
`android` in the list is the sharp end: it is not an x86-64 platform, and an artifact declared for it
|
||||||
|
today would be an x86-64 binary wearing the label. Nothing would say so until a machine tried to run
|
||||||
|
it.
|
||||||
|
|
||||||
|
**And the field reads as implemented.** It is required, validated against a closed list, and refused
|
||||||
|
with a careful message — every signal a manifest author gets says the mesh is acting on it. A field
|
||||||
|
that is checked and ignored is worse than one that does not exist, because the check is what persuades
|
||||||
|
you it works.
|
||||||
|
|
||||||
|
## Two things this is not
|
||||||
|
|
||||||
|
- **Not the same axis as the distribution.** `alpine`, `android`, `arch` are what a machine reports
|
||||||
|
itself to be, and the comment on the list says why: "the difference between two of them is a C
|
||||||
|
library, not a kernel". The processor is a second dimension and the manifest has no word for it at
|
||||||
|
all — so even a correct implementation of the current field would not answer the question that
|
||||||
|
started this.
|
||||||
|
- **Not urgent for this mesh.** Four machines, all x86-64 Arch, one build machine. Nothing is broken
|
||||||
|
today and nothing will be until a machine differs — which is exactly how long a field like this stays
|
||||||
|
invisible.
|
||||||
|
|
||||||
|
## Where to look
|
||||||
|
|
||||||
|
The compile invocation is assembled in `mesh-controller internal/builder`, and for Go it would need
|
||||||
|
`GOOS`/`GOARCH` set from the artifact rather than inherited from the build machine. That needs the
|
||||||
|
manifest to carry a processor as well as a system, or the systems list to mean both — which is a
|
||||||
|
decision, not a fix, and belongs with whoever answers whether one static binary should serve several
|
||||||
|
distributions at all.
|
||||||
|
|
||||||
|
**That last question is live.** The Go toolchain builds statically, so a single binary has no C library
|
||||||
|
to differ about and would in fact run on Alpine and Arch alike. The per-system pin is then a policy — a
|
||||||
|
host refuses a machine it was not built for — rather than a technical necessity, and worth knowing is a
|
||||||
|
choice.
|
||||||
|
|
||||||
|
## How a fix is checked
|
||||||
|
|
||||||
|
An artifact declared for a system the build machine is not produces a binary for that system, shown by
|
||||||
|
reading the file rather than by the build reporting success; and two artifacts declared for two systems
|
||||||
|
do not have the same digest.
|
||||||
Reference in New Issue
Block a user