mirror of
https://github.com/astral-sh/setup-uv.git
synced 2026-07-21 12:29:40 +00:00
f12b1f0a84
## Summary `getLinuxOSNameVersion()` throws `Failed to determine Linux distribution. Could not read /etc/os-release or /usr/lib/os-release` on distributions whose os-release is readable but contains **no version field at all** — no `VERSION_ID`, no `VERSION_CODENAME`, no `BUILD_ID`. The error message is misleading in that case, and the action fails even though the distribution is perfectly identifiable. Void Linux is such a distribution. Its os-release is: ```sh $ cat /etc/os-release NAME="Void" ID="void" PRETTY_NAME="Void Linux" HOME_URL="https://voidlinux.org/" DOCUMENTATION_URL="https://docs.voidlinux.org/" LOGO="void-logo" ANSI_COLOR="0;38;2;71;128;97" DISTRIB_ID="void" ``` Unlike Arch (fixed by #912 via `BUILD_ID`) and debian:unstable (fixed via `VERSION_CODENAME`, #773), Void ships only `ID`, so both existing fallbacks miss it. This breaks any workflow using `container: ghcr.io/void-linux/void-glibc-full` with caching enabled — e.g. SageMath's CI started failing after bumping to v8: https://github.com/sagemath/sage/actions/runs/29456228986/job/87489892141 (worked around downstream in https://github.com/sagemath/sage/pull/42547 by injecting a fake `BUILD_ID` into the container's os-release). This PR adds a last-resort fallback: if `ID` is present but no version field is, return the plain `ID` (`void`), following the same reasoning as #912 — a stable cache key for a rolling release is better than crashing. Distributions with a version field are unaffected, and files without even an `ID` still raise the existing error.