pthbs

Packaging Through Hashed Build Scripts
git clone https://ccx.te2000.cz/git/pthbs
Log | Files | Refs | Submodules | README

README (3185B)

      1 Packaging Through Hashed Build Scripts
      2 ======================================
      3 
      4 Lower half of a package management system.
      5 
      6 Package versioning scheme inspired by Stow/Nix/Guix and also partly by
      7 slashpackage convention.
      8 
      9 See Minimal Reliable Reproducible Linux <https://ccx.te2000.cz/stagit/mrrl/>
     10 for package database to be used with pthbs.
     11 
     12 See https://ccx.te2000.cz/stagit/pthbs_genpkgpy/ for Jinja-based templating
     13 system for generating package definitions for pthbs.
     14 
     15 How this works
     16 --------------
     17 
     18 Each package definition is actually a shell script that has all the instructions
     19 to build the software in question as well as hash of any installed software or
     20 sources it needs, either in form of sha256sum or git commit id.
     21 
     22 This shell script is then hashed with sha256 and the result is appended to
     23 package name to form unique installation directory for that specific
     24 configuration.
     25 This way you are not limited from installing multiple versions or build
     26 configurations of software and switching between them freely.
     27 
     28 These package installations then are combined into environments (similar to
     29 profiles in Nix) implemented using symlink forest and are again identified by
     30 their content hash.
     31 
     32 The packaging system itself is intended to pose as building block for larger
     33 system configuration management suite that allows for atomic software and
     34 configuration updates, A/B boot with rollback options, etc., without trying to
     35 tell you how those should be managed.
     36 
     37 Dependencies of the package build and installation system are kept intentionally
     38 as slim as possible.
     39 Currently it's all done using busybox utilities and GNU make and this list is
     40 expected to stay final.
     41 
     42 However, package dependency management can be very complex.
     43 This design decouples the complexity of determining which software fits together
     44 in desired configuration (which easily leads into combinatorial explosion) from
     45 the packaging tool itself.
     46 
     47 Currently the software packaged in MRRL is hand-picked minimal set, but there is
     48 nothing preventing creation of a sophisticated package specification generator
     49 on top of an efficient constraint solving algorithm and PTHBS should work as a
     50 solid lower half for that.
     51 
     52 Features
     53 --------
     54 
     55 Implemented features
     56 ~~~~~~~~~~~~~~~~~~~~
     57 
     58 * per-package build options
     59   * `sandbox` prevents access outside explicit dependencies (default=on)
     60   * `set_path` configures PATH to given build environment (default=on)
     61 * build sources
     62   * git commit id
     63   * file sha256
     64     * extract tarballs, including compression
     65     * automatically download when URL provided in downloadlist.sha256
     66 * collects build logs and prints errors
     67 * uses parallel with inferred job count by default
     68 * build sandbox for regular user builds
     69   * using simple user namespace based (and possibly not very secure) python script
     70   * using syd <https://git.sr.ht/~alip/syd> (requires recent kernel)
     71 * ensure all installed binaries are statically linked
     72 
     73 Work in progress
     74 ~~~~~~~~~~~~~~~~
     75 
     76 Planned features
     77 ~~~~~~~~~~~~~~~~
     78 
     79 * build sandbox with segregated build users using only packaged software
     80 * fully reproducible builds
     81 * bootstrap sanboxing binaries
     82 * rewrite `sandbox.py` in C and build it during bootstrap