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.
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 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
# Disable stripping (add this line only if needed).
make DESTDIR="$1" install
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.
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
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
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
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
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
The patches directory should contain any patches the software needs. In the
sources file patches are referred to by using a relative path (
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
patch -p1 < rxvt-unicode-kerning.patch
patch -p1 < gentables.patch
make DESTDIR="$1" install
files/ directory should contain any miscellaneous files the software needs. In the
sources file, files are referred to by using a relative path (
The build script has direct access to the files in its current working directory.
Example build file with files
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"