An Exherbo gcc base image with the third-party repositories
already installed, synced and metadata-cached, so cave resolve is usable right away.
Repositories added on top of the upstream base: CleverCloud, heirecka, net,
python, ruby, rust, tombriden, virtualization.
Published for linux/amd64 and linux/arm64:
docker run --rm -it ghcr.io/davlgd/exherbo:latest
Tags: latest and a dated YYYYMMDD snapshot per build.
GitHub Actions builds each architecture on a native runner (ubuntu-24.04 and
ubuntu-24.04-arm), pushes it by digest to GHCR, then merges both into a single
manifest list. It runs on every push to master, weekly on Mondays, and on demand
via Run workflow. Pull requests build without pushing.
Each run resolves the newest dated tag of the matching upstream base image
(exherbo/exherbo-x86_64-pc-linux-gnu-gcc-base,
exherbo/exherbo-aarch64-unknown-linux-gnueabi-gcc-base) and passes it as a build
argument, so the weekly rebuild actually picks up the refreshed base.
No secret to configure: the workflow authenticates with the built-in GITHUB_TOKEN,
and the published package inherits the repository's visibility.
docker buildx build --platform linux/amd64 -t exherbo:local --load .The FROM lines are pinned to dated base tags, so a local build is reproducible.
Override them to build against a different base:
docker buildx build \
--build-arg BASE_TAG_AMD64=20260820 \
--platform linux/amd64 -t exherbo:local --load .Everything happens in a single RUN: cave sync must stay in the same layer as the
resolves that depend on it, otherwise Docker's cache can hand back an image whose
repositories are months old. Pass --build-arg CACHEBUST=$(date +%s) to force a
fully fresh build.
Note that the build compiles packages from source and is slow; emulated cross-builds
(--platform linux/arm64 on an x86_64 host) are slower still, which is why CI uses
native runners for both.
MIT, see LICENSE. The Exherbo distribution and the packages it builds have their own licenses.