Keru splits its world into repositories so each stays small and legible. The package side of that is:
| Repo | Holds | Keeps |
|---|
| kama | The manager — the kama entry point and lib/kama.sh core. | The code. |
| kama-packages | The recipe repository — one .sh per package. | The knowledge. |
| KeruOS | The OS: installer, profile, build pipeline, live init. | The orchestration. |
| keru | This website — docs, news, and everything you're reading. | The word. |
Where the repos live
github.com/AstralZX/kama # the manager (canonical)
github.com/AstralZX/kama-packages # the recipe repository (canonical)
github.com/AstralZX/KeruOS # the OS itself (canonical)
github.com/AstralZX/keru # this website (canonical)
git.spectoria.dev/AstralZX/... # mirrors of all of the above
The canonical host is GitHub: three code repos plus this site's repo. Mirrors of all of them live on git.spectoria.dev. They are read-mirrors — push and issues stay on GitHub, and the mirrors can fall behind by however long it's been since the last sync. A Codeberg mirror is also under consideration.
No package recipes ship on the ISO, in the installer, or anywhere else. The recipe repository on GitHub is how you get packages — clone it or install Keru, which fetches it at build time.
Why separate
- Independent cadence. The manager changes rarely; recipes change constantly. Mixing them couples an ossified core to churn.
- Clear ownership. "Which file builds busybox?" — the recipe repo. "How does kama decide to stage?" — the manager repo. No guessing where things live.
- Small repos, legible diffs. A PR adding a package touches exactly one file in one repo.
- Cross-repo defaults. Keru's scripts expect the three repos as siblings (
kama next to kama-packages next to KeruOS), and every path is overridable via KAMA_DIR / PKGS_DIR.
How they fit together
# KeruOS build-root.sh drives kama against kama-packages
KAMA="$KAMA_DIR/kama" # the manager
PKGDIR="$PKGS_DIR" "$KAMA" make "$pkg" # a recipe, executed
# into $ROOT — a completed system, built from source.
The installer is the conductor: it writes your make.conf, then calls the build pipeline, which runs kama over recipes to produce exactly the system you chose.
This is Keru's answer to packaging sprawl: four tiny repos, each human-sized, instead of one monolith that swallowed everything.
← Kama overview · The build pipeline