Keru splits its world into three 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, website. | The orchestration. |
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: three tiny repos, each human-sized, instead of one monolith that swallowed everything.
← Kama overview · The build pipeline