Ship a musl/Alpine package so Alpine is supported, not just refused

[ebursztein]

Why

The glow-up platform matrix now runs the package on Alpine 3.21–3.24 and proves it cannot run there:

ok  Alpine 3.24            musl 1.2.6     cannot run, as declared
ok  Alpine 3.23            musl 1.2.5     cannot run, as declared
ok  Alpine 3.22            musl 1.2.5     cannot run, as declared
ok  Alpine 3.21            musl 1.2.5     cannot run, as declared

Proving the refusal is honest, but the goal is to serve those users. musl is not an older glibc, so lowering the glibc floor (#181) does nothing here — it needs a separately linked package.

Scope

This is real work, not a packaging flag:

1. Link the host cohort against musl. x86_64-unknown-linux-musl and aarch64-unknown-linux-musl are already in the toolchain (the guest agent cohort uses them), so the pure-Rust binaries — capsem, capsem-service, capsem-process, capsem-tui, capsem-mcp*, capsem-gateway, capsem-admin, capsem-mock-server, capsem-bench-rs — are the tractable part.
2. Decide what happens to capsem-app. The Tauri shell links webkit2gtk/GTK. Alpine carries those, but Tauri on musl is the unproven piece. A CLI/service-only Alpine package may be the right first cut, with the desktop shell out of scope.
3. Service registration. The installer emits systemd units on Linux; Alpine is OpenRC. generate_unit() gains a sibling, and the install/uninstall/update paths need to select between them.
4. .apk packaging and signing, alongside the existing .deb and macOS .pkg rails.
5. install.sh currently hard-fails without apt; it needs an apk branch.
6. Manifest and release lanes carry a third artifact family.

Done when

The four Alpine rows in [platforms.linux.distributions] flip from cannot run to runs, driven by the musl package rather than by editing the expectation. The proof derives the expectation from each image's real libc, so it follows this change without being updated.

Related

• deb declares no libc dependency: installs cleanly on older distros, then every binary fails #174 — the deb declared no libc floor at all (fixed)
• Lower the release glibc floor to cover every supported Debian/Ubuntu #181 — lower the glibc floor to cover Ubuntu 22.04 / Debian 12

[ebursztein]

Spike result: 40 of 41 errors are one mechanical fix

Both musl targets and musl-gcc are already present on a dev host, so no toolchain work is needed to start. cargo build --target x86_64-unknown-linux-musl -p capsem-core fails (exit 101) with 41 errors, but they are not 41 problems:

Count	Error	Where
40	E0308: expected i32, found u64	hypervisor/kvm/sys.rs (39), virtio_vsock.rs (1)
1	E0277: *mut c_void cannot be sent between threads safely	hypervisor/kvm/vcpu.rs:289

The 40 are all the same line of thinking. musl types the ioctl request argument as c_int; glibc types it as c_ulong. Every site is a variation of:

let ret = unsafe { libc::ioctl(fd, request as libc::c_ulong, arg) };
//                                 ^^^^^^^^^^^^^^^^^^^^^^^^ expected i32, found u64 on musl

That is one cfg-selected alias plus a mechanical replacement of the cast:

#[cfg(target_env = "musl")]
pub type IoctlRequest = libc::c_int;
#[cfg(not(target_env = "musl"))]
pub type IoctlRequest = libc::c_ulong;

On glibc the alias resolves to exactly what is written there today, so the change is a no-op for every currently shipped target.

The 1 is the only real design question. A raw *mut c_void is captured by a thread spawned in vcpu.rs:289 and musl's binding makes it !Send where glibc's did not. It needs a small wrapper asserting the pointer is safe to move to the vcpu thread, with the reasoning written down — not a cast.

Everything is confined to hypervisor/kvm/. Nothing in the service, CLI, MCP, logger, or gateway layers objected to musl at all, which is the part that would have been expensive.

Revised scope

Step 1 of the issue ("link the host cohort against musl") is substantially smaller than written. The open questions are still steps 2–6: capsem-app/Tauri on musl, OpenRC service registration, .apk packaging and signing, the apk branch in install.sh, and a third artifact family in the release lanes.

Not landing this yet

The fix is small but it is in the hypervisor ioctl layer, and a binaries release for 0.6 is in flight against a qualified commit. Landing it now would mean requalifying the KVM layer on the way out the door for no 0.6 benefit. Queued for immediately after 0.6 ships.

[ebursztein]

ort also blocks #181, so removing it unblocks both

#181 tried to lower the release glibc floor by moving the build base to Ubuntu 22.04. It failed at package.arm64.build — prebuilt ONNX Runtime objects will not cross-link for aarch64 on jammy (undefined reference to __cxa_call_terminate), and that is not fixed by a newer cross compiler: the symbol is defined in both gcc-11 and gcc-12 libstdc++.a there.

So the same dependency stands in front of both platform expansions:

	blocked by
#182 musl / Alpine	ort-sys publishes no musl binaries; ort-tract is not on crates.io
#181 glibc 2.35 floor	prebuilt ONNX Runtime aarch64 objects will not cross-link on jammy

capsem-service is the only crate pulling ort, via magika. Removing it clears both, from one change.

Re-measured, the removal is small: dropping magika produces 2 errors, both in fs_utils.rs. The 13 main.rs references point at wrapper functions, not at magika. And the degraded path already exists — identify_file_sync returns ("unknown", "application/octet-stream", "unknown", false) on any magika error, and callers are written for it, so a build without magika takes a path the service already takes rather than a new one.