commit a3f91f1098d5c9127fc679d0ff32b0b7aa9bde81
parent 05c56da9ed88fd63cfc79bedc2a205d05d8dff39
Author: Jan Pobříslo <ccx@te2000.cz>
Date: Thu, 15 Jun 2023 01:38:29 +0200
Add README
Diffstat:
| A | README | | | 104 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 file changed, 104 insertions(+), 0 deletions(-)
diff --git a/README b/README
@@ -0,0 +1,104 @@
+Packaging Through Hashed Build Scripts
+======================================
+
+Not a distro. Barely a packaging system.
+
+Intent of this project is to build robust, minimal Linux-based system that is
+just enough to boot, start some containers (via unshare and pidns patch to s6),
+and rebuild itself.
+
+It should be fully compatible with installation as a software overlay over
+existing Linux distributions.
+
+The robustnes should come from two design decisions:
+* picking simple software that does it's job right
+* package versioning scheme inspired by Stow/Nix/Guix and also partly by
+ slashpackage convention
+
+How this works
+--------------
+
+Each package definition is actually a shell script that has all the instructions
+to build the software in question as well as hash of any sources it needs,
+either in form of file sha256sum or of git commit id.
+
+This shell script is then hashed with sha256 and the result is appended to
+package name to form unique installation directory for that specific
+configuration.
+This way you are not limited from installing multiple versions or build
+configurations of software and switching between them freely.
+
+These package installations then are combined into environments (similar to
+profiles in Nix) implemented using symlink forest and are again identified by
+their content hash.
+
+The packaging system itself is intended to pose as building block for larger
+system configuration management suite that allows for atomic software and
+configuration updates, A/B boot with rollback options, etc., without trying to
+tell you how those should be managed.
+
+Dependencies of the package build and installation system are kept intentionally
+as slim as possible.
+Currently it's all done using busybox utilities and GNU make and this list is
+expected to stay final.
+
+However, package dependency management can be very complex.
+This design decouples the complexity of determining which software fits together
+in desired configuration (which easily leads into combinatorial explosion) from
+the packaging tool itself.
+
+The software packaged here is hand-picked minimal set, but there is nothing
+preventing creation of a sophisticated package specification generator on top of
+an efficient constraint solving algorithm and should work as a solid base for
+that.
+
+Requirements
+------------
+
+The bootstrap is done by compiling musl-cross-make.
+Ideally you should not need anything above requirements of that project but
+currently the reproducible build checks are implemented using explicit calls to
+busybox binary. (TODO)
+
+For regenerating the package build scripts from templates you will also need
+Python3 and Jinja2.
+
+Packaged software
+-----------------
+
+* busybox
+* execline
+* gnu-make
+* mdevd
+* musl-cross-make
+* s6
+* s6-dns
+* s6-linux-init
+* s6-linux-utils
+* s6-networking
+* s6-portable-utils
+* s6-rc
+* skalibs
+
+Planned packages
+----------------
+
+* bison
+* flex
+* linux
+* libretls
+* curl
+* git
+* netbsd-curses
+* zsh
+* cgroup-tools (cgconfigparser)
+* libcap (execcap tool)
+* ... more iff needed
+
+Planned features
+----------------
+
+* build sandbox
+* fully reproducible builds
+* rewrite Python package generator into something easier to bootstrap on
+ POSIX-ish system (AWK?)
