Does the official Blender Linux tarball (as this image currently downloads from download.blender.org/release/) run under Alpine/musl as-is, via gcompat, or not at all? Is
there a musl-friendly alternative that still supports headless .blend import for Godot (e.g. an
Alpine apk community Blender package, a different distribution channel, or a Flatpak-style
approach) — and if none exists, does that alone rule out Alpine for this effort?
## Question
Does the official Blender Linux tarball (as this image currently downloads from
`download.blender.org/release/`) run under Alpine/musl as-is, via `gcompat`, or not at all? Is
there a musl-friendly alternative that still supports headless `.blend` import for Godot (e.g. an
Alpine `apk` community Blender package, a different distribution channel, or a Flatpak-style
approach) — and if none exists, does that alone rule out Alpine for this effort?
Part of [Smaller/faster godot-ci image (map)](https://git.arthurerlich.de/haylan/godot-ci/issues/2).
Researched: the official Blender Linux tarball (glibc >=2.28 required per blender.org) does NOT run on Alpine/musl as-is, and gcompat is not a credible fix for something Blender's size/complexity — gcompat's own docs say it only patches pre-built glibc binaries and 'some will still not work'; the one concrete community attempt (ikester/blender-docker PR#1) tried exactly this and failed with missing libs/unresolved glibc symbols. A musl-native alternative does exist — Alpine community's blender-headless package (5.2.0-r0) built for exactly this headless-import use case — but it's only on Alpine's edge branch, not a stable release, which is a real strike against Alpine for a pipeline that wants pinned versions. Full writeup + sources: https://git.arthurerlich.de/haylan/godot-ci/src/branch/research/blender-musl-alpine/docs/research/blender-musl-alpine.md
Researched: the official Blender Linux tarball (glibc >=2.28 required per blender.org) does NOT run on Alpine/musl as-is, and gcompat is not a credible fix for something Blender's size/complexity — gcompat's own docs say it only patches pre-built glibc binaries and 'some will still not work'; the one concrete community attempt (ikester/blender-docker PR#1) tried exactly this and failed with missing libs/unresolved glibc symbols. A musl-native alternative does exist — Alpine community's blender-headless package (5.2.0-r0) built for exactly this headless-import use case — but it's only on Alpine's edge branch, not a stable release, which is a real strike against Alpine for a pipeline that wants pinned versions. Full writeup + sources: https://git.arthurerlich.de/haylan/godot-ci/src/branch/research/blender-musl-alpine/docs/research/blender-musl-alpine.md
Resolution already recorded on Smaller/faster godot-ci image (map)'s Decisions-so-far and acted on in ticket #7's resolution. Closing — this was left open by an oversight, not because it's still active.
Resolution already recorded on [Smaller/faster godot-ci image (map)](https://git.arthurerlich.de/haylan/godot-ci/issues/2)'s Decisions-so-far and acted on in [ticket #7](https://git.arthurerlich.de/haylan/godot-ci/issues/7)'s resolution. Closing — this was left open by an oversight, not because it's still active.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Question
Does the official Blender Linux tarball (as this image currently downloads from
download.blender.org/release/) run under Alpine/musl as-is, viagcompat, or not at all? Isthere a musl-friendly alternative that still supports headless
.blendimport for Godot (e.g. anAlpine
apkcommunity Blender package, a different distribution channel, or a Flatpak-styleapproach) — and if none exists, does that alone rule out Alpine for this effort?
Part of Smaller/faster godot-ci image (map).
Researched: the official Blender Linux tarball (glibc >=2.28 required per blender.org) does NOT run on Alpine/musl as-is, and gcompat is not a credible fix for something Blender's size/complexity — gcompat's own docs say it only patches pre-built glibc binaries and 'some will still not work'; the one concrete community attempt (ikester/blender-docker PR#1) tried exactly this and failed with missing libs/unresolved glibc symbols. A musl-native alternative does exist — Alpine community's blender-headless package (5.2.0-r0) built for exactly this headless-import use case — but it's only on Alpine's edge branch, not a stable release, which is a real strike against Alpine for a pipeline that wants pinned versions. Full writeup + sources: https://git.arthurerlich.de/haylan/godot-ci/src/branch/research/blender-musl-alpine/docs/research/blender-musl-alpine.md
Resolution already recorded on Smaller/faster godot-ci image (map)'s Decisions-so-far and acted on in ticket #7's resolution. Closing — this was left open by an oversight, not because it's still active.