Dieses Dokument beschreibt, welche Möglichkeiten Rezepte bieten, mit den Kochwerkzeugen („cookutils“) in einem Wok und mit Tazpkg Pakete für SliTaz zu erzeugen. Rezepte werden auch von Tazpkg beim Installieren und Deinstallieren von Paketen sowie zur Ausgabe von Informationen über ein Paket verwendet. Jedes Rezept beginnt mit einem Kommentar in Englisch:

# SliTaz package receipt

Die ersten fünf Variablen sollten immer vorhanden und nicht leer sein. Der Paketname wird in der Variablen PACKAGE angegeben, danach folgt die Version, die Kategorie zu der das Paket gehört, eine kurze Beschreibung und der Name des Betreuers. Für das Paket clex, eine Dateiverwaltung, kann das so aussehen:

PACKAGE="clex"
VERSION="3.16"
CATEGORY="base-apps"
SHORT_DESC="Text mode file manager."
MAINTAINER="pankso@slitaz.org"

Die Kochwerkzeuge kennen noch weitere, optionale Variablen. So kann beispielsweise der Name anderer Quellcode-Pakete angegeben werden. Weitere Variablen werden von Tazpkg benötigt, um Abhängigkeiten aufzulösen oder Informationen über das Paket bereitzustellen.

• DEPENDS: Benennt Pakete, die von dem Paket für seine Funktionsfähigkeit benötigt werden. Mehrere benötigte Pakete können durch Leerzeichen getrennt oder auf mehrere Zeilen verteilt angegeben werden. Diese Variable wird vor allem von Tazpkg bei der Installation des Pakets und von den Kochwerkzeugen beim Erzeugen großer Pakete wie Xorg verwendet. Clex benötigt beispielsweise das Paket ncurses:

DEPENDS="ncurses"

• BUILD_DEPENDS: Benennt Pakete, die beim Erzeugen des Paketes benötigt werden. Auch hier können mehrere Pakete angegeben werden. Diese Variable wird von den Kochwerkzeugen beim Erzeugen eines Pakets verwendet. Beispiel:

BUILD_DEPENDS="ncurses-dev"

• TARBALL: Das Quellcode-Archiv mit der Erweiterung tar.gz, tgz oder tar.bz2. In der Regel werden die Variablen PACKAGE und VERSION nur zum Ändern der Erweiterung verwendet, es hilft somit das Paket zu aktualisieren, ohne die Variable VERSION zu ändern. Allgemeines Beispiel (siehe auch Beispiel bei SOURCE):

TARBALL="$PACKAGE-$VERSION.tar.gz"

• WEB_SITE: Die offizielle Internetpräsenz für das Paket. Es kann sein, dass es bei einigen Bibliotheken keine Internetpräsenz gibt. In diesem Fall ist es nicht erforderlich, einen URL anzugeben. Beachten Sie aber, dass die Kochwerkzeuge und Tazpkg beide einen URL mit der kompletten HTTP-Adresse erwarten:

WEB_SITE="http://www.clex.sk/"

• WGET_URL: URL, der angibt, von wo das Quellcode-Archiv transferiert werden kann. Im Allgemeinen sollte die Variable TARBALL verwendet werden, um die Aktualisierung des Pakets zu erleichtern, ohne die Variable VERSION zu ändern. Bei Verwendung einer Konfigurationsdatei werden von den Kochwerkzeugen standardmäßig auch drei weitere Quellcode-Depots definiert in den Variablen GNU_MIRROR für GNU-Software, SF_MIRROR für SourceForge und XORG_MIRROR für die Software des Grafischen Server Xorg. Beispiel für Clex:

WGET_URL="http://www.clex.sk/download/$TARBALL"

• CONFIG_FILES: Einige Pakete enthalten vordefinierte Konfigurationsdateien. Die Variable CONFIG_FILES enthält eine Liste dieser Dateien, die mit tazpkg repack-config gesichert werden können. Diese Dateien werden bei einer Neuinstallation des Paketes nicht überschrieben, wenn sie bereits vorhanden sind. Das Paket kann dann mit tazpkg repack neu erstellt werden, auch wenn die Konfigurationsdateien modifiziert wurden. Beispiel für Netatalk:

CONFIG_FILES="/etc/netatalk/AppleVolumes.* /etc/netatalk/*.conf"

• SUGGESTED: Benennt weitere nützliche Pakete, die aber nicht notwendig sind. Wird auch zum Aktivieren von optionalen Funktionen verwendet.
• WANTED: SliTaz Pakete sind normalerweise abhängig von der Übersetzung der Quellpakete. Manchmal enthält das Rezept keine Vorschrift für das Erzeugen eines Paketes. Dann wird der Inhalt der Variablen WANTED verwendet, um Quelldateien von einem anderen Paket unter Verwendung der Variablen src zu kopieren
• SOURCE: Es kann vorkommen, dass der Name des SliTaz-Paketes von dem Namen des Quellcode-Paketes abweicht. Ein Beispiel dafür findet sich bei den Xorg-Paketen: Der Name der X11-Bibliothek bei SliTaz ist xorg-libX11, während der Name des Quellcode-Paketes libX11 ist. Mit der Variablen SOURCE ist es möglich, bei der Erzeugung des Paketes die Variablen src und install zu verwenden. Beachten Sie, dass bei libX11 das Quellcode-Archiv zu $SOURCE-$VERSION.tar.gz wird.
• PROVIDE: Einige Pakete bieten dieselbe Funktionalität. So war z.B. zuerst lighttpd der Webserver, jetzt kann auch apache verwendet werden. Alle Pakete, die einen Webserver benötigen, verweisen auf lighttpd. Die Variable PROVIDE=“lighttpd” in dem Rezept von apache zeigt an, dass Pakete, die von lighttpd abhängen, das Paket lighttpd nicht benötigen, wenn apache bereits installiert ist. Einige Pakete können sich abhängig vom Webserver unterscheiden; so wird etwa das Paket php von lighttpd benötigt, aber das Paket php-apache von apache. Die Variable PROVIDE=“php:apache” in dem Rezept von apache zeigt an, dass php-apache anstelle von php installiert werden muss, wenn apache bereits installiert ist. Daher wird jedes Paket, das PHP benötigt, entweder php-apache oder php installieren, abhängig davon, welcher Webserver installiert ist. Über diese Variable werden auch Pakete ausgewählt, die mit verschiedene Optionen übersetzt wurden. Die Variable PROVIDE=“epdfview:cups” in dem Rezept von epdfview-cups ermöglicht die Installation von epdfview mit Druckerunterstützung durch cups, wenn cups bereits installiert ist.
  

Mithilfe dieser Variablen können auch virtuelle Pakete definiert werden. Die Zeilen PROVIDE=“libgl” im Rezept des Paketes mesa und PROVIDE=“libgl:nvidia” in dem von nvidia-glx legen fest, dass libgl eine optimierte Version ist, wenn das Paket nvidia installiert ist.

• SELF_INSTALL (obsolet): Einige Pakete führen Kommandos aus, die in der Funktion post_install des Paketes stehen. Um diese Pakete in ein anderes Verzeichnis als das Wurzelverzeichnis / installieren zu können und dennoch die Möglichkeit zu haben, diese Kommandos auszuführen, muss das Paket früher einmal im Wurzelverzeichnis / installiert worden sein. Die Variable SELF_INSTALL=1 macht tazpkg darauf aufmerksam. Diese Variable ist überholt. Stattdessen kann chroot “$1/” ein_kommando_des_pakets in der Funktion post_install verwendet werden.

Bestimmte Tatsachen sind nur bei oder nach der Erzeugung eines Paketes bekannt. Die Kochwerkzeuge fügen die entsprechenden Variablen automatisch in das Rezept ein.

• PACKED_SIZE: Größe der tazpkg-Datei.

• UNPACKED_SIZE: Nach der Installation vom Paket belegter Speicherplatz.

• EXTRAVERSION: Einige Pakete haben zwei verschieden Versionen, z.B. Module die den Linux-Kern ergänzen, wie etwa squashfs, denn solche Module hängen auch von der Version des Linux-Kerns ab, mit der sie übersetzt wurden. In diesem Fall enthält EXTRAVERSION die Version des Linux-Kerns und die Kochwerkzeuge bestimmen den Modul aus dem Inhalt von /lib/modules.

Die Kochwerkzeuge setzen mehrere Variablen, die die Übersetzung und Erzeugung von Paketen für SliTaz erleichtern. Diese Variablen werden automatisch von den Kochwerkzeugen anhand der Informationen in einem Rezept gesetzt; sie können von den Funktionen compile_rules und genpkg_rules genutzt werden, die im Abschnitt Funktionen beschrieben sind.

• src: Bestimmt den Pfad zu einem Verzeichnis nicht archivierter Quellen.

• install: Bestimmt den Pfad zu den übersetzten Objektprogrammen, die mittels make DESTDIR=$DESTDIR install erzeugt wurden. Diese Variable wird zum Kopieren der erzeugten Dateien und zum Packen von Paketen verwendet.

• _pkg: wie install.

• fs: Bestimmt den Pfad zu dem Pseudo-Dateisystem fs in jedem paket. Das Verzeichnis fs des Paketes entspricht dem Wurzeldateisystem von SliTaz; so findet man Clex z.B. als $fs/usr/bin/clex. Beachten Sie, dass die nötigen Verzeichnisse in der Funktion genpkg_rules() erzeugt werden müssen, bevor Dateien kopiert werden können.

• CONFIGURE_ARGS: Diese Variable wird in der Konfigurationsdatei cook.conf der Kochwerkzeuge gesetzt. Damit ist es möglich, generische Optimierungsparameter für die Erzeugung eines Paketes festzulegen. Standardwert ist die Architektur i486.

• DESTDIR: Bestimmt den Pfad für die Installation der übersetzten Objektprogramme, die mittels make DESTDIR=$DESTDIR install erzeugt wurden.

Ein Rezept kann vier Funktionen enthalten. Die Kochwerkzeuge verwenden die Funktionen compile_rules, die Regeln für die Übersetzung von Quellprogrammen enthält und genpkg_rules, die Regeln für das Packen des Paketes enthält. Diese Funktionen können alle möglichen GNU/Linux-Standard-Kommandos enthalten, z.B. sed, awk, patch und die automatisch gesetzten Variablen verwenden.

Um die Quellprogrammene eines Paketes zu übersetzen, kann mit der Variablen src das Verzeichnis, das die Quellprogramme enthält, als Arbeitsverzeichnis eingestellt werden (cd) und dann aus CONFIGURE_ARGS Parameter aus der Konfigurationsdatei der Kochwerkzeuge übernommen werden. Normalerweise wird das Paket dann mit make ohne irgendwelche Argumente erzeugt, soll es im Verzeichnis $DESTDIR installiert werden, so ist make DESTDIR=$DESTDIR install anzugeben. Allgemeines Beispiel:

# Rules to configure and make the package.
compile_rules()
{
	cd $src
	./configure --prefix=/usr --infodir=/usr/share/info \
	--mandir=/usr/share/man $CONFIGURE_ARGS
	make
	make DESTDIR=$DESTDIR install (oder einfach make install)
}

Um ein SliTaz-Paket zu erzeugen, müssen entsprechende Kommandos in der Funktion genpkg_rules angegeben werden. In diesem Beispiel wird ein Pseudo-Verzeichnis /usr in dem Dateisystem des Paketes erstellt, dorthin alle Objektdateien kopiert und daraus die Symbolinformationen entfernt:

# Rules to gen a SliTaz package suitable for Tazpkg.
genpkg_rules()
{
	mkdir -p $fs/usr
	cp -a $install/usr/bin $fs/usr
	strip -s $fs/usr/bin/*
}

Diese Funktionen werden von Tazpkg ausgeführt, wenn ein Paket installiert wird. Sie müssen im Rezept enthalten sein, bevor das Paket mit den Kochwerkzeugen erstellt wird. Wenn diese Funktionen keine Regeln enthalten, sind sie sinnlos und können entfernt werden. Ein Beispiel mit echo zur Ausgabe von irgendwelchem Text (keine FunKtion sollte leer sein):

# Pre and post install commands for Tazpkg.
pre_install()
{
	echo "Processing pre-install commands..."
}
post_install()
{
	echo "Processing post-install commands..."
}

Diese Funktionen werden von Tazpkg ausgeführt, wenn ein Paket deinstalliert wird. Sie müssen im Rezept enthalten sein, bevor das Paket mit den Kochwerkzeugen erstellt wird. Wenn diese Funktionen keine Regeln enthalten, sind sie sinnlos und können entfernt werden. Ein Beispiel mit echo zur Ausgabe von irgendwelchem Text (keine FunKtion sollte leer sein):

# Pre and post remove commands for Tazpkg.
pre_remove()
{
	echo "Processing pre-remove commands..."
}
post_remove()
{
	echo "Processing post-remove commands..."
}