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.


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 \

make DESTDIR="$1" install


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


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

Example sources file with optional fields gcc gcc/gmp gcc/mpfr gcc/mpc


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


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
f222991a00d8b30f1aaee5991bb9a8b624023e4a38cef46a1eddf2c8a55cfd3d  busybox.conf


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



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


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 \

make DESTDIR="$1" install


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"

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