commit 3e11914d6780ec07a26b4f587b3df1b13c0f32e5
parent d6d194d358312d6c31ada66fbb53cd183f87d6f3
Author: Jan Pobrislo <ccx@te2000.cz>
Date: Mon, 11 Nov 2024 02:21:24 +0000
Split out MRRL info from README file
Diffstat:
| M | README | | | 95 | ++++++++++--------------------------------------------------------------------- |
1 file changed, 12 insertions(+), 83 deletions(-)
diff --git a/README b/README
@@ -1,19 +1,16 @@
Packaging Through Hashed Build Scripts
======================================
-Not a distro. Barely a packaging system.
+Lower half of a package management 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.
+Package versioning scheme inspired by Stow/Nix/Guix and also partly by
+slashpackage convention.
-It should be fully compatible with installation as a software overlay over
-existing Linux distributions.
+See https://ccx.te2000.cz/stagit/mrrl/ for package database to be used with
+pthbs.
-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
+See https://ccx.te2000.cz/stagit/pthbs_genpkgpy/ for Jinja-based templating
+system for generating package definitions for pthbs.
How this works
--------------
@@ -47,21 +44,10 @@ 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.
+Currently the software packaged in MRRL 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 PTHBS should work as a
+solid lower half for that.
Features
--------
@@ -93,61 +79,4 @@ Planned features
* build sandbox with segregated build users using only packaged software
* fully reproducible builds
* bootstrap sanboxing binaries
-* rewrite Python package generator into something easier to bootstrap with on
- POSIX-ish system (AWK?)
-
-Packages
---------
-
-Packaged software
-~~~~~~~~~~~~~~~~~
-
-* busybox
-* execline
-* gnu-make
-* mdevd
-* musl-cross-make
- * including gmp, intl, mpc, mpfr, zlib
-* s6
-* s6-dns
-* s6-linux-init
-* s6-linux-utils
-* s6-portable-utils
-* s6-rc
-* skalibs
-* popt
-* m4
-* flex
-* bison
-* patch
-* diffutils
-* netbsd-curses
-* s6-networking
-* libressl
-* curl
-* zsh
-* git
-* apk
-* xbps
-* zstd
-
-Work in progress
-~~~~~~~~~~~~~~~~
-
-* versioned system configuration including init
- * statically link more modules
-* rsync
- * add acl and xattr support
-* linux
- * build fully-featured kernel for real hardware
-* libelf
-* consider openssl for env-specific certificate lists
-
-Planned packages
-~~~~~~~~~~~~~~~~
-
-* TLS certificates
-* cgroup-tools (cgconfigparser)
-* libcap (execcap tool)
-* ... more iff needed
-
+* rewrite `sandbox.py` in C and build it during bootstrap
