Package System

The distribution employs a package system based around the concept of easily parseable plain-text files (separated by lines and spaces). This format allows effortless interface using any programming language or just basic UNIX tools.

Directory Structure

zlib/            # Package name.
├─ build         # Build script (must be executable).
├─ depends       # Dependencies (usually required).
├─ sources       # Remote and local sources.
├─ version       # Package version.
┘

# Files generated by the package manager.
├─ checksums     # Checksums for the source files.
├─ manifest      # Tracked files.
┘

# Optional files.
├─ post-install  # Post-install script (must be executable).
├─ patches/*     # Directory to store patches.
├─ files/*       # Directory to store misc files.
┘

build

The build file should contain all of the steps necessary to patch, configure, make and install (make install in this context) the package.

The script is language agnostic and the only requirement is that it be executable. On execution the script will start in the directory of the package’s source (there is no need to change the working directory).

The script is also given a single argument (equivalent to script arg), this argument contains the path where the script should install the compiled files. Everything in the path is added to the package tarball and later installed to the system.

Example build file

#!/bin/sh -e

# Disable stripping (add this line only if needed).
:> nostrip

./configure \
    --prefix=/usr

make
make DESTDIR="$1" install

depends

The depends file should contain any other packages the package depends on to function correctly. Each dependency should be listed one per line and an optional second field allows for the distinction between a compile time dependency and a run time one.

Example depends file

# Comments are also supported.
perl make
zlib

sources

The sources file should contain all remote and local files the package needs to be built. This includes the source, patches and any other miscellaneous files which may be needed.

Each source should be listed one per line. An optional second field specifies an extraction directory (relative to the build directory).

Example sources file

https://roy.marples.name/downloads/dhcpcd/dhcpcd-8.0.2.tar.xz
files/dhcpcd.run

Example sources file with optional fields

https://gcc.gnu.org/pub/gcc/releases/gcc-9.1.0/gcc-9.1.0.tar.xz gcc
https://gmplib.org/download/gmp/gmp-6.1.2.tar.xz gcc/gmp
http://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.xz gcc/mpfr
https://ftp.gnu.org/gnu/mpc/mpc-1.1.0.tar.gz gcc/mpc
files/c99

version

The version file should contain a single line with two fields. The first field should contain the software’s upstream version and the second field should contain the version number of the repository files themselves.

Example version file

1.2.3 1

checksums

The checksums file is generated by the package manager and contains the sha256sum of all remote and local sources. This ensures most of all that the source downloaded matches the source the KISS developers used to build and install the software.

When creating a “KISS” package, kiss checksum pkg will download the remote sources and generate the checksums file. This command can then be run again to update the checksums in the case of a package update.

Example checksums file

0e4925392fd9f3743cc517e031b68b012b24a63b0cf6c1ff03cce7bb3846cc99  busybox-1.31.0.tar.bz2
e942bc7e2274e15136a964bb3628b21fab3460327f3c7eb097e02f5faaaee93b  .config
6c3eb5cf839c7a31c337df0cd8388b397e1415ffa7a63e9678552c9c63dd869f  acpid.run
814dea14ac612125e97dcc1d619219b2c9dfc14850bf48d858421fb2c98eca12  crond.run
4a5981f4b0d791fe9b84b0b2e01ae905f6565c8245b3cd603e6decf34ddad71a  syslogd.run
f222991a00d8b30f1aaee5991bb9a8b624023e4a38cef46a1eddf2c8a55cfd3d  busybox.conf

manifest

The manifest file is generated by the package manager and contains the full list of tracked files and directories. The package manager uses this file to install packages, remove packages, detect package conflicts and to detect library dependencies.

Files are listed first with directories following in reverse order. This enables the package removal process to easily remove empty directories as it starts with the deepest files and traverses upwards.

Example manifest file

/var/db/kiss/installed/zlib/version
/var/db/kiss/installed/zlib/sources
/var/db/kiss/installed/zlib/manifest
/var/db/kiss/installed/zlib/depends
/var/db/kiss/installed/zlib/checksums
/var/db/kiss/installed/zlib/build
/var/db/kiss/installed/zlib/
/var/db/kiss/installed/
/var/db/kiss/
/var/db/
/var/
/usr/share/man/man3/zlib.3
/usr/share/man/man3/
/usr/share/man/
/usr/share/
/usr/lib/pkgconfig/zlib.pc
/usr/lib/pkgconfig/
/usr/lib/libz.so.1.2.11
/usr/lib/libz.so.1
/usr/lib/libz.so
/usr/lib/libz.a
/usr/lib/
/usr/include/zlib.h
/usr/include/zconf.h
/usr/include/
/usr/

post-install

The post-install file should contain anything that needs to be run after a package installation to properly setup the software.

The script is language agnostic and the only requirement is that it be executable.

Example post-install file

#!/bin/sh -e

/usr/sbin/update-ca-certificates --fresh

patches/*

The patches directory should contain any patches the software needs. In the sources file patches are referred to by using a relative path (patches/musl.patch).

The package manager does not automatically apply patches. This must be done in the build script of the package. The build script has direct access to the patches in its current working directory.

Example build file with patches

#!/bin/sh -e

patch -p1 < rxvt-unicode-kerning.patch
patch -p1 < gentables.patch

./configure \
    --prefix=/usr \
    --with-terminfo=/usr/share/terminfo \
    --enable-256-color \
    --disable-utmp \
    --disable-wtmp \
    --disable-lastlog

make DESTDIR="$1" install

files/*

The files/ directory should contain any miscellaneous files the software needs. In the sources file, files are referred to by using a relative path (files/busybox.config).

The build script has direct access to the files in its current working directory.

Example build file with files

#!/bin/sh -e

install -D kiss "$1/usr/bin/kiss"

# 'kiss_path.sh' is stored in 'files/kiss_path.sh'.
# The build script has direct access to it and it is
# added to the final tarball under /etc/profile.d/kiss_path.sh.
install -D kiss_path.sh "$1/etc/profile.d/kiss_path.sh"