2026-08-06 22:41:52 +00:00
1 changed files with 208 additions and 0 deletions
@@ -0,0 +1,208 @@
 # Is a glibc-based slim distro (e.g. debian-slim) a better fit than Alpine?
 Research for [wayfinder ticket #8](https://git.arthurerlich.de/haylan/godot-ci/issues/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
 - https://hub.docker.com/_/debian/tags — Docker Hub official `debian` image tags (bookworm-slim, trixie-slim compressed sizes)
 - https://hub.docker.com/_/ubuntu/tags — Docker Hub official `ubuntu` image tags (noble compressed size)
 - https://packages.debian.org/bookworm/mingw-w64
 - https://packages.debian.org/bookworm/gcc-mingw-w64-x86-64
 - https://packages.debian.org/bookworm/libx11-dev
 - https://packages.debian.org/search?keywords=libgl1-mesa-dev&searchon=names&suite=all&section=all
 - https://packages.debian.org/search?keywords=libwayland-dev&searchon=names&suite=all&section=all
 - https://packages.debian.org/bookworm/libc6
 - https://www.blender.org/download/requirements/ (glibc ≥2.28 requirement; matches #5's citation of the same page)
 - `docs/research/godot-musl-alpine.md` (branch `research/godot-musl-alpine`) — ticket #4 findings on Godot/musl
 - `docs/research/blender-musl-alpine.md` (branch `research/blender-musl-alpine`) — ticket #5 findings on Blender/musl
 - `docs/research/mingw-w64-alpine.md` (branch `research/mingw-w64-alpine`) — ticket #6 findings on Alpine mingw-w64
 - This repo's `Dockerfile` — current `barichello/godot-ci` (Ubuntu Noble) base and full `apt-get install` package list