pthbs_genpkgpy

Template engine for producing packages for pthbs written using Python and Jinja
git clone https://ccx.te2000.cz/git/pthbs_genpkgpy
Log | Files | Refs | README

README (4481B)


      1 Packaging Through Hashed Build Scripts
      2 ======================================
      3 
      4 Not a distro. Barely a packaging system.
      5 
      6 Intent of this project is to build robust, minimal Linux-based system that is
      7 just enough to boot, start some containers (via unshare and pidns patch to s6),
      8 and rebuild itself.
      9 
     10 It should be fully compatible with installation as a software overlay over
     11 existing Linux distributions.
     12 
     13 The robustnes should come from two design decisions:
     14 * picking simple software that does it's job right
     15 * package versioning scheme inspired by Stow/Nix/Guix and also partly by
     16   slashpackage convention
     17 
     18 How this works
     19 --------------
     20 
     21 Each package definition is actually a shell script that has all the instructions
     22 to build the software in question as well as hash of any installed software or
     23 sources it needs, either in form of sha256sum or git commit id.
     24 
     25 This shell script is then hashed with sha256 and the result is appended to
     26 package name to form unique installation directory for that specific
     27 configuration.
     28 This way you are not limited from installing multiple versions or build
     29 configurations of software and switching between them freely.
     30 
     31 These package installations then are combined into environments (similar to
     32 profiles in Nix) implemented using symlink forest and are again identified by
     33 their content hash.
     34 
     35 The packaging system itself is intended to pose as building block for larger
     36 system configuration management suite that allows for atomic software and
     37 configuration updates, A/B boot with rollback options, etc., without trying to
     38 tell you how those should be managed.
     39 
     40 Dependencies of the package build and installation system are kept intentionally
     41 as slim as possible.
     42 Currently it's all done using busybox utilities and GNU make and this list is
     43 expected to stay final.
     44 
     45 However, package dependency management can be very complex.
     46 This design decouples the complexity of determining which software fits together
     47 in desired configuration (which easily leads into combinatorial explosion) from
     48 the packaging tool itself.
     49 
     50 The software packaged here is hand-picked minimal set, but there is nothing
     51 preventing creation of a sophisticated package specification generator on top of
     52 an efficient constraint solving algorithm and should work as a solid base for
     53 that.
     54 
     55 Requirements
     56 ------------
     57 
     58 The bootstrap is done by compiling musl-cross-make.
     59 Ideally you should not need anything above requirements of that project but
     60 currently the reproducible build checks are implemented using explicit calls to
     61 busybox binary. (TODO)
     62 
     63 For regenerating the package build scripts from templates you will also need
     64 Python3 and Jinja2.
     65 
     66 Features
     67 --------
     68 
     69 Implemented features
     70 ~~~~~~~~~~~~~~~~~~~~
     71 
     72 * per-package build options
     73   * `sandbox` prevents access outside explicit dependencies (default=on)
     74   * `set_path` configures PATH to given build environment (default=on)
     75 * build sources
     76   * git commit id
     77   * file sha256
     78     * extract tarballs, including compression
     79     * automatically download when URL provided in downloadlist.sha256
     80 * collects build logs and prints errors
     81 * uses parallel with inferred job count by default
     82 * build sandbox for regular user builds
     83   * using simple user namespace based (and possibly not very secure) python script
     84   * using syd <https://git.sr.ht/~alip/syd> (requires recent kernel)
     85 * ensure all installed binaries are statically linked
     86 
     87 Work in progress
     88 ~~~~~~~~~~~~~~~~
     89 
     90 Planned features
     91 ~~~~~~~~~~~~~~~~
     92 
     93 * build sandbox with segregated build users using only packaged software
     94 * fully reproducible builds
     95 * bootstrap sanboxing binaries
     96 * rewrite Python package generator into something easier to bootstrap with on
     97   POSIX-ish system (AWK?)
     98 
     99 Packages
    100 --------
    101 
    102 Packaged software
    103 ~~~~~~~~~~~~~~~~~
    104 
    105 * busybox
    106 * execline
    107 * gnu-make
    108 * mdevd
    109 * musl-cross-make
    110   * including gmp, intl, mpc, mpfr, zlib
    111 * s6
    112 * s6-dns
    113 * s6-linux-init
    114 * s6-linux-utils
    115 * s6-portable-utils
    116 * s6-rc
    117 * skalibs
    118 * popt
    119 * m4
    120 * flex
    121 * bison
    122 * patch
    123 * diffutils
    124 * netbsd-curses
    125 * s6-networking
    126 * libressl
    127 * curl
    128 * zsh
    129 * git
    130 * apk
    131 * xbps
    132 * zstd
    133 
    134 Work in progress
    135 ~~~~~~~~~~~~~~~~
    136 
    137 * versioned system configuration including init
    138   * statically link more modules
    139 * rsync
    140   * add acl and xattr support
    141 * linux
    142   * build fully-featured kernel for real hardware
    143 * libelf
    144 * consider openssl for env-specific certificate lists
    145 
    146 Planned packages
    147 ~~~~~~~~~~~~~~~~
    148 
    149 * TLS certificates
    150 * cgroup-tools (cgconfigparser)
    151 * libcap (execcap tool)
    152 * ... more iff needed
    153