archlinux-pkgs-debloated

Previously known as 'llvm-libs-debloated'

---

This repo makes modified versiones of Archlinux packages, these are intended for AppImages to reduce final size, like:

• mesa-mini and vulkan-{radeon,intel,etc}-mini remove linking to libLLVM.so, making any hardware accelerated app tiny as result.

• mesa-nano and vulkan-{radeon,intel,etc}-nano similar to mesa-mini, built with -Os which makes it ~30% smaller. Note -Os can have a performance and even stability issue so do not use this package in apps like emulators where this is critical.

• llvm-libs-mini smaller version of libLLVM.so which is a 150+ MiB library, this version is reduced down to 99 MiB.

• llvm-libs-nano, similar to mini, but with the llvm targets limited (x86_64 or aarch64) + AMDGPU, this reduces the size of the library to less than 70 MiB. Note this will cause issues if application depends on more llvm targets like compilers.

• qt6-base-mini and libxml2-mini, remove 30 MiB libicudata lib dependency.

• ffmpeg-mini which removes 20 MiB libx265.so dependency, also removes AV1 enconding support (decoding still works).

• ffmpeg-nano a much more stripped down ffmpeg that only decodes mp3, opus, vorbis, png and jpeg (no encoders, no hardware acceleration, no external codec libraries).

• sdl2_image-mini removes AVIF and JPEG-XL support from SDL2_image. AVIF pulls in libavif plus the whole AV1 codec family (libaom, SvtAv1Enc, rav1e, dav1d) and JPEG-XL pulls libjxl — ~23 MiB combined that most apps never use. PNG/JPG/TIFF/WEBP still work.

• opus-mini I have no idea why Archlinux makes this lib 5 MiB when both ubuntu and alpine make it <500 KiB

• glycin-mini Builds glycin-ng, alternative to glycin that does not have the many problems that GNOME glycin has. This replaces the old gdk-pixbuf2-mini/librsvg-mini workaround.

• icu-mini Much smaller version of libicudata.so that is less than 3 MIB in size (10x reduction in size).

• gtk2-mini Builds gtk2-ng-git, a community-maintained fork of GTK2.

• libdecor-mini Builds libdecor-rs, rust implementation of libdecor without GTK/D-Bus dependencies (Ideal for SDL apps).

Projects using these packages

• Anylinux-AppImages - ghostty, citron and many more

• goverlay

• Steam-appimage

• interstellar

• QDiskInfo

• mangojuice

• CPU-X

• ppsspp

• Eden

CI

Build jobs run inside ghcr.io/pkgforge-dev/archlinux-builder:<arch>, an image that bakes in base-devel, ccache, clang, cmake, curl, git, mold, ninja and wget plus the initialized pacman keyring. The main win is keeping the toolchain in one place instead of installing it per job. On the GitHub-hosted native legs the ~2 GB image is pulled fresh on every job, so wall time there is roughly a wash versus installing the toolchain.

The image is built per arch by the build builder image workflow and refreshed weekly, so its package database can be up to a week old; prepare-build falls back to the old pacman -Syu install when the toolchain is missing, which also keeps the workflow usable with a plain ghcr.io/pkgforge-dev/archlinux base.

Run build builder image manually once before the first build after merging (and whenever the Dockerfile changes). That first run pushes the package as private; the build jobs have packages: read and build-emulated logs in to ghcr, so they can still pull it. Making the package public in its settings is optional but matches the other pkgforge images.

PKGBUILDs and version sync with the archlinux forks

The emulated arches build from the PKGBUILD of their own archlinux port (bin/get-port-pkgbuild):

• ppc64le, ppc64: the complete PKGBUILD from ArchPOWER.
• riscv64: the Archlinux PKGBUILD plus riscv64.patch (and the extra files next to it) from archriscv-packages.
• loongarch64: the same with loong.patch from loongarch-packages.

The riscv64 and loongarch64 ports only patch the packages that need it. For the others the plain Archlinux PKGBUILD is used. It is the one tagged ([epoch-]pkgver-pkgrel) with the version the port repo carries, not the latest one. A patch that does not apply cleanly fails the build.

A package is only built when its PKGBUILD version equals the version that the pacman repositories of the target architecture carry (bin/check-upstream-version, compared as strings). This avoids partial updates. On the emulated arches those repositories are the ones of the respective port, which can lag behind Archlinux. The build is skipped when the versions differ, when there is no Archlinux tag for the version the port carries (the port uses its own pkgrel), or when the port does not carry the package. FORCE_BUILD=2 builds anyway.