An artifact's system is checked and then nothing uses it #208

2026-09-30T08:30:46Z

jschoubben commented

2026-09-30 08:30:46 +00:00

Asked whether the host is built for more than one architecture. It is not, and the reason is worse than a missing feature.

A bundle in a compiled language must name a system, must name one of alpine/android/arch, and is refused with a careful message otherwise. The field is 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 compile runs with no target named and produces a binary for whatever the build machine happens to be.

The host is x86-64 because the build machine is, not because the declaration said so. Correct for this mesh by coincidence.

A module declaring two systems would get two identical binaries, both published and both pinned, and the one sent to the machine it was not built for would fail at exec. android is the sharp end.

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 notes for whoever fixes it: the processor is a second dimension the manifest has no word for, and since the Go toolchain builds statically one binary would run on all three systems anyway — so the per-system pin is a policy rather than a necessity, which is a decision and not a fix.

Asked whether the host is built for more than one architecture. It is not, and the reason is worse than a missing feature. A bundle in a compiled language **must** name a system, must name one of `alpine`/`android`/`arch`, and is refused with a careful message otherwise. The field is 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 compile runs with no target named and produces a binary for whatever the build machine happens to be. The host is x86-64 because the build machine is, not because the declaration said so. Correct for this mesh by coincidence. A module declaring two systems would get two identical binaries, both published and both pinned, and the one sent to the machine it was not built for would fail at exec. `android` is the sharp end. 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 notes for whoever fixes it: the processor is a second dimension the manifest has no word for, and since the Go toolchain builds statically one binary would run on all three systems anyway — so the per-system pin is a policy rather than a necessity, which is a decision and not a fix.

jschoubben added 1 commit 2026-09-30 08:30:47 +00:00

An artifact's system is checked and then nothing uses it 4bf4fe2d06

Asked whether the host is built for more than one architecture. It is
not, and the reason is worse than a missing feature.

A bundle in a compiled language must name a system, must name one of
alpine, android or arch, and is refused with a careful message if it gets
that wrong. The field is 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 compile runs with no target named and produces a
binary for whatever the build machine happens to be.

The host is x86-64 because the build machine is, not because the
declaration said so. Correct for this mesh by coincidence — four machines,
all x86-64 Arch.

A module declaring two systems would get two identical binaries, both
published and both pinned, and the one sent to the machine it was not
built for would fail at exec. android is the sharp end: not an x86-64
platform, and an artifact declared for it today would be an x86-64 binary
wearing the label.

A field that is checked and ignored is worse than one that does not
exist, because the check is what persuades you it works.

Also noted: the processor is a second dimension the manifest has no word
for, so even implementing the present field would not answer the question
that found this. And since the Go toolchain builds statically, one binary
would run on all three systems anyway — so the pin is a policy rather
than a necessity, which is a decision and not a fix.

jschoubben merged commit b19b29cd3a into main

2026-09-30 08:30:53 +00:00

jschoubben deleted branch issue/159-an-artifacts-system-is-checked-and-ignored

2026-09-30 08:30:53 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#208