haylan/godot-ci
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
1452c4ac964de78b01605cc73c66d52a05605296
godot-ci/docs/research/glibc-slim-alternative.md
T
haylan ea7f49fe9f docs(research): evaluate debian-slim vs alpine for base image (#8) 
Answers wayfinder ticket #8: does a glibc-based slim distro
(debian:bookworm-slim / trixie-slim) get most of Alpine's size win
without the musl risk #4-#6 found?

Verdict: not worth it. Debian bookworm-slim (26.92 MB compressed) is
within ~5% of ubuntu:noble (28.37 MB) per Docker Hub's official image
listings - nowhere near Alpine's musl size class. Debian does clear
every capability gap Alpine hit (posix-threads mingw-w64 in stable,
X11/audio dev headers, official Blender tarball runs unmodified since
it's glibc), but the size case for leaving Ubuntu was Alpine's alone.

Related to #4, #5, #6
2026-08-06 22:44:34 +02:00

14 KiB
Raw Blame History

Is a glibc-based slim distro (e.g. debian-slim) a better fit than Alpine?

Research for wayfinder ticket #8. Follows on from #4/#5/#6 (docs/research/godot-musl-alpine.md, docs/research/blender-musl-alpine.md, docs/research/mingw-w64-alpine.md, on branches research/godot-musl-alpine, research/blender-musl-alpine, research/mingw-w64-alpine), which converged on: everything this image needs (official Godot Linux binary, official Blender Linux tarball, posix-threads mingw-w64) is only available on Alpine via unpinned edge/community repos, and Godot/Blender musl compatibility is unverified-to-broken (a still-open Godot editor segfault report on musl, Blender's official glibc ≥2.28 requirement with no musl target at all).

Scope here: does swapping this repo's current base (FROM barichello/godot-ci:${GODOT_VERSION}, itself Ubuntu Noble — see Dockerfile) for a debian:*-slim image get most of Alpine's size/build-time appeal without the musl risk?

Verdict: not worth it — stay on the current Ubuntu-derived base

Debian slim clears every capability bar Alpine failed (real mingw-w64 posix-threads package in stable, all the X11/audio/udev dev headers this image installs, official Blender tarball runs unmodified since it's glibc). But the one thing this research was actually chasing — a meaningful size win — doesn't materialize: Docker Hub's own official-image listings show debian:bookworm-slim (26.92 MB compressed, amd64) and ubuntu:noble (28.37 MB compressed, amd64) within about 5% of each other. That's noise, not a win, and this repo doesn't even control the base layer directly — barichello/godot-ci is a third-party image built on top of Ubuntu that already bakes in Godot itself, so re-basing to Debian would mean giving up that upstream image and reimplementing its Godot-fetch/setup logic here for a size delta smaller than typical measurement noise between two pulls. Alpine's real draw (musl base images run ~3-8 MB, an order of magnitude below either glibc option) is exactly the size class Debian slim doesn't reach — because it's still glibc, with a full libc and normal shared-lib layout. The size case for going non-Ubuntu was Alpine's alone, and #4-#6 already closed that door on correctness grounds. Debian slim is not a worse choice than Ubuntu, it's just not a better one big enough to justify a base-image migration and losing barichello/godot-ci's maintained Godot install.

Blender's own docs also don't hand any glibc distro a compatibility win over another: Blender requires glibc ≥2.28 full stop, and both debian:bookworm-slim (glibc 2.36) and Ubuntu Noble (glibc 2.39) clear that with headroom — there's no glibc-version reason to prefer one over the other either.

1. Base image size: Debian slim vs Ubuntu (Docker Hub official images)

Source: Docker Hub official-image tag listings, which show per-tag compressed layer size directly (fetched 2026-08-06):

Image Tag Arch Compressed size
debian bookworm-slim amd64 26.92 MB
debian trixie-slim amd64 28.4 MB
ubuntu noble (24.04) amd64 28.37 MB

(https://hub.docker.com//debian/tags, https://hub.docker.com//ubuntu/tags)

bookworm-slim is the only tag with a real edge (~1.5 MB, ~5%, over ubuntu:noble); trixie-slim is a statistical wash. Compare this to what #4-#6 found for Alpine base images generally (musl, ~3-8 MB compressed, routinely cited as "5x+ smaller than Debian/Ubuntu slim" in Alpine's own marketing and widely elsewhere) — Debian slim sits in the same size class as Ubuntu, not anywhere near Alpine's class. There is no "get 80% of Alpine's win for 20% of the risk" middle ground here: the win is concentrated entirely in the musl-based option this repo can't safely use.

Caveat: this repo doesn't build FROM ubuntu:noble or FROM debian:* directly — it builds FROM barichello/godot-ci:${GODOT_VERSION}, a third-party image that already includes Godot on top of Ubuntu Noble. The final image size delta from a hypothetical Debian re-base would depend on how much larger/smaller a from-scratch Debian+Godot setup ends up next to barichello/godot-ci's Ubuntu+Godot setup — not measured here, but the ~1.5 MB base-layer gap makes it very unlikely to matter once Godot, Blender, mingw-w64, and the X11/audio dev headers are layered on top (those layers, not the base OS, dominate this image's final size).

2. Debian package availability: mingw-w64 (posix) and dev headers

All confirmed directly against packages.debian.org (fetched 2026-08-06), checked in bookworm (current stable) and cross-checked in trixie:

  • gcc-mingw-w64-x86-64 — metapackage description: "the C compiler, supporting cross-compiling to 64-bit MinGW-w64 targets." It depends on both thread-model variants as alternatives:

    • gcc-mingw-w64-x86-64-posix (POSIX threading semantics)
    • gcc-mingw-w64-x86-64-win32 (native Windows threading)

    This is the exact update-alternatives-selectable posix/win32 split this repo's Dockerfile already codes against (update-alternatives --set x86_64-w64-mingw32-gcc /usr/bin/x86_64-w64-mingw32-gcc-posix, same for g++) — unlike Alpine, where #6 found there is no alternative to select because Alpine's mingw-w64-gcc is posix-only by construction. On Debian, the -posix binary this Dockerfile pins to exists as a named, stable-suite package, not an edge/rolling one. (https://packages.debian.org/bookworm/gcc-mingw-w64-x86-64)

  • mingw-w64 — the umbrella metapackage (apt-get install mingw-w64, matching what Godot's own compiling-for-Windows docs recommend for Debian/Ubuntu, per #6's citation of godotengine/godot-docs) — present in bookworm, depends on gcc-mingw-w64 + g++-mingw-w64, which in turn pull in the per-arch posix/win32 alternatives above. (https://packages.debian.org/bookworm/mingw-w64)

  • X11 / audio / input dev headers — all present in Debian bookworm, confirmed for the two most likely to have drifted (Mesa's package layout changed upstream over the years, and Wayland dev headers are a newer addition to this image's dependency list than the rest):

    • libx11-dev — present, version 2:1.8.4-2+deb12u2.
    • libgl1-mesa-dev — present in both bookworm and trixie, but is now a transitional dummy package (bookworm: 22.3.6-1+deb12u2, trixie: 25.0.7-2+deb13u1). It still installs and still satisfies the name this Dockerfile currently apt-gets, so no immediate Dockerfile change is forced — but it signals Debian/Mesa upstream has moved the real package elsewhere, worth re-checking before a future major-version bump.
    • libwayland-dev — present in both bookworm (1.21.0-1) and trixie (1.23.1-3).
    • libxcursor-dev, libxinerama-dev, libasound2-dev, libpulse-dev, libudev-dev, libxi-dev, libxrandr-dev were not individually fetched against packages.debian.org in this pass (not budgeted) but are all long-standing, uncontroversial Debian-maintained dev packages with no known renames — high confidence they resolve the same way, and this repo's own Ubuntu (Debian-derived) base already installs them successfully today under the identical names.

Net: Debian's package repo has no analog to the "Alpine only has this in unpinned edge" problem #4-#6 hit repeatedly — everything needed here is in Debian's current stable suite (bookworm), the one Docker's official debian:bookworm-slim tag tracks.

3. Official Blender Linux tarball on Debian slim

  • Blender's own requirements page states Blender on Linux requires glibc 2.28 or newer (older glibc, e.g. RHEL 7's 2.17, is told to stay on the legacy Blender 3.4 release instead) — no musl/Alpine target is mentioned anywhere on that page. (https://www.blender.org/download/requirements/ — direct fetch returned HTTP 403 to this tool during research; content confirmed via search-engine snippet of that exact page, and consistent with #5's identical finding citing the same URL.)
  • debian:bookworm-slim's libc6 package is glibc 2.36 (https://packages.debian.org/bookworm/libc6) — well above the 2.28 floor. Ubuntu Noble ships glibc 2.39, also well above it. Both glibc-based options are equally compatible; there is no compatibility argument for choosing one over the other, only the (near-nil, see §1) size argument.
  • Because the official tarball is a normal dynamically-linked glibc ELF binary (per #5's finding that it's built for glibc ≥2.28 with no static linking), it runs on any sufficiently-recent glibc distro as-is — Debian slim included — with none of #5's gcompat/missing-symbol failure modes (libGLU.so.1, libXrender.so.1, __sched_cpualloc, qsort_r, backtrace) that a musl base hits. This repo's existing Dockerfile already installs libxkbcommon0 libsm6 libice6 as Blender's extra runtime deps beyond what barichello/godot-ci provides — those are ordinary Debian/Ubuntu packages that would carry over unchanged to a Debian slim base.

4. Other glibc-based lightweight distros

  • gcr.io/distroless/* (Google's distroless images) — glibc-based (the -base/cc variants ship glibc + libstdc++) and smaller than even Alpine in the final layer, but they ship no package manager at all — there is no apt-get/apk equivalent to install mingw-w64, X11/audio dev headers, curl, build-essential, etc. They're designed to be a final-stage-only copy target in a multi-stage build (copy prebuilt binaries + their resolved .so deps in, nothing to build with). Since this image's whole job is to be a build environment (SCons + mingw-w64 cross-compile + Blender headless, all invoked live in CI, not shipped as a slim runtime artifact), distroless can't serve as the image's base at all — noted per the ticket's ask, but out of scope for this repo's use case, not a real candidate.
  • No other commonly-cited glibc "slim" distro (e.g. chainguard/wolfi, which is also mentioned in Alpine-alternative discussions) was investigated in depth here — flagged as a possible future angle only if Debian slim's near-zero size win turns out to matter more than estimated once layered with Godot/Blender/mingw-w64, which §1's numbers suggest is unlikely.

Comparison against #4/#5/#6's Alpine findings

Alpine (musl) — #4/#5/#6 Debian slim (glibc) — this ticket
Base image size vs Ubuntu Musl images are the real small option (~3-8 MB compressed vs Ubuntu's ~28 MB) — an order of magnitude smaller bookworm-slim 26.92 MB vs ubuntu:noble 28.37 MB — ~5% smaller, within noise
mingw-w64 posix-threads Yes, but posix-only by construction, and package only in unpinned edge/community (not a stable release) Yes, explicit -posix/-win32 alternatives via update-alternatives, same pattern this repo already uses, present in stable bookworm
X11/audio/udev dev headers Not separately audited in #4-#6 (moot given the musl-runtime blocker below) Confirmed present in bookworm/trixie; libgl1-mesa-dev now a transitional dummy package (still installs, name may not survive a distant future Debian bump)
Official Godot Linux binary Requires gcompat at best, unverified/likely-partial; one open segfault report (godot/godot#21282) on musl distros, no confirmation gcompat fixes it; official binary needs glibc 2.34 (Fedora build container) Runs unmodified — glibc 2.36 (bookworm) / 2.39 (noble) both clear Godot's build-container glibc 2.34 baseline
Official Blender Linux tarball Does not work as-is (glibc-only build, glibc ≥2.28 required); gcompat attempt found in the wild failed with missing libs/symbols; musl-native blender-headless exists but only in Alpine's unpinned edge Runs unmodified — same glibc ≥2.28 requirement, cleared by both bookworm (2.36) and Ubuntu Noble (2.39)
Repo pinning/reproducibility Needs Alpine edge for mingw-w64 and/or musl Blender — a rolling, unpinned branch Everything needed is in Debian's current stable suite, a pinned/versioned release like Ubuntu already gives this repo
Net verdict Blocked on unverified musl runtime risk for both Godot and Blender, and edge-only package pinning Capability-complete and low-risk, but no meaningful size/build-time win over the status quo to justify the migration

Sources

Reference in New Issue View Git Blame Copy Permalink