Slackware-Packages mit protopkg erstellen

Mit protopkg hat David Cantrell ein Programm zur einfachen Erstellung von Slackware-Packages entwickelt.

Die Idee hinter protopkg

Nachdem im letzten Artikel mit encap ein distributionsunabhängiges Werkzeug zum Tracken installierter Software vorgestellt wurde, geht es diesmal spezifisch zu. Mit protopkg hat David Cantrell ein Programm zur einfachen Erstellung von Slackware-Packages entwickelt. Hierfür wird eine Datei namens prototype geschrieben, die sowohl Informationen zur Software an sich als auch über den Installationvorgang enthält. prototype-Dateien bieten so eine ausgezeichnete Möglichkeit, mit anderen Usern Packages auszutauschen, diese anzupassen, oder den Prozeß der Kompilierung (durch einen Blick auf die compile-Funktion) nachvollziehen zu können.

Installation und allgemeiner Aufbau einer prototype-Datei

protopkg liegt als Tarball und Slackware-Packages auf dem FTP-Server oder einem entsprechenden Mirror. Die Installation erfolgt beim Tarball durch folgende Schritte:

./Build.sh
cp protopkg /usr/local/sbin
cat protopkg.8 | gzip -9c > /usr/local/man/man8/protopkg.8.gz

Das fertige Package wird wie folgt installiert:

installpkg protopkg-2.0-noarch.tgz

Unter /usr/doc/protopkg (falls Sie protopkg kompiliert haben, empfiehlt es sich, die Dateien aus dem Verzeichnis doc der Source-Distribution dorthin zu kopieren) befindet sich nach der Installation eine prototype-Vorlage, auf die näher einzugehen ist:

IGNOREPATH=<Variable der zu ignorierenden Verzeichnisse.
 Mit dieser Variable wird festgelegt, was protopkg bei
 der Suche nach Dateien, die ins Package gelangen sollen,
 auslassen kann.>
STRIPLIB=[y|n] # STRIPLIB legt fest, ob protopkg alle
 dynamischen Bibliotheken strippen soll.
STRIPBIN=[y|n] # Neben den dynamischen Bibliotheken können
 auch die ausführbaren Dateien automatisch gestrippt werden.
SETATTR=[y|n] # SETATTR steht für "set attributes" und legt
 fest, ob von den Slackware-Standards für Besitzer und
 Zugriffsrechte Gebrauch gemacht werden soll (alle Dateien
 in einem /bin oder /sbin Verzeichnis gehören demnach root.bin
 und sind auf 0755 gesetzt. Sämtliche Manpages wandern nach
 /usr/man, gehören root.root und haben die Zugriffsrechte 0644).
 Diese Variable ist per Default auf 'y' gesetzt. Sie können
 SETATTR explizit den Wert 'y' geben oder aber protopkg durch
 das Setzen auf 'n' dazu veranlassen, den genannten Standard
 zu ignorieren.
# Informationen über die vorliegende Software
VERSION=<Version der Software>
PROGNAME=<Name der Software>
DESC=<Beschreibung der Software>
# Angaben zum/vom Package Maintainer
BUILD=<Build-Nummer des Packages>
MAINTAINER=<Name und beispielsweise auch die Email-Adresse des Maintainers>
PKGNAME=<Der Name des Packages>
# Funktionen
compile() {
 #
 # Diese Funktionen kompiliert die Software.
 #
 # Es kann sich auf $CWD und $TMP bezogen werden.
 # $CWD steht für Current Working Directory. In diesem Verzeichnis
 # befinden sich die Quellen. $TMP ist das temporäre Verzeichnis,
 # welches protopkg bei der Erstellung nutzt. (/tmp/build-$PKGNAME)
}
install() {
 # Auch hier lässt sich wohl direkt der Sinn der Funktion
 # vom Namen her ableiten. Die Dateien werden in den root-Baum,
 # (also /) installiert.
 #
 # $CWD und $TMP können auch hier zum Einsatz kommen.
}
attributes() {
 #
 # Bevor das Package schliesslich erstellt wird, kopiert protopkg
 # es nach $PKG, damit letzte Änderungen, wie beispielsweise
 # das Setzen von Zugriffsrechten/Besitzern durchgeführt werden können.
 # In dieser Funktion können desweiteren $CWD, $TMP und $CTL
 # referenziert werden.
 # $CTL ist das Package-Kontrollverzeichnis. In dieses Verzeichnis
 # wandert das doinst.sh Skript, welches in zahlreichen
 # prototype-Dateien per "echo"-Anweisungen modifiziert wird.
}
special() {
 #
 # special() stellt eine Funktion für die allerletzten
 # Modifikationen vor der finalen Erstellung dar.
 #
 # $CWD, $TMP, $PKG und $CTL können hier referenziert werden.
}
subpacks() {
 #
 # Die Funktion subpacks() existiert lediglich für den Aufruf
 # von repack(), wodurch "Subpackages" erstellt werden. Mehr
 # dazu später.
}

Eine simple exemplarische prototype

Nachdem nun auf den Aufbau einer prototype-Dateien in der Theorie eingegangen worden ist, soll nun, analog zum Encap-Artikel, anhand der Terminalemulation rxvt der praktische Umgang beleuchtet werden.

Zunächst sollte zur besseren Übersicht ein neues Verzeichnis erstellt werden, in dem zunächst die sources-Datei aus 2.1 platziert wird. Anschließend geht es an das Schreiben der prototype:

IGNOREPATH

Diese Variable muß der gegebenen Partitionierung und den Vorlieben zur Ausnutzung der jeweiligen Verzeichnisse im root-Tree angepaßt werden. Mein üblicher Eintrag lautet hierfür beispielsweise:

 IGNOREPATH=/boot:/dev:/home:/mnt:/proc:/root:/tmp

STRIPLIB & STRIPBIN

Generell ist es stets eine gute Idee, diese beiden Variablen auf 'y' zu setzen, demnach:

 STRIPLIB=y
 STRIPBIN=y

Angaben zur Software

Die ersten beiden Variablen sind wohl selbsterklärend. "DESC" sollte möglichst kurz und präzise die Software beschreiben.

 VERSION=2.6.3
 PROGNAME=rxvt
 DESC="A VT102 emulator for the X window system."

Informationen vom/über den Maintainer

Dies ist der erste Build, folgerichtig: BUILD=1
In der Variable MAINTAINER wird der Name des Maintainers des Packages eingetragen. Schließlich wird durch die SOURCE=ftp://ftp.rxvt.org/pub/rxvt/ ausgedrückt, dass die Originalsourcen von rxvt unter dieser URL heruntergeladen werden können.
Falls Sie ihr Package anderen Usern zur Verfügung stellen wollen, so sollten Sie in bei LOCATION die Bezugsquelle eintragen.

Der Package-Name

Dies liegt natürlich in Ihrem Ermessen. Falls Sie beispielsweise für mehrere Plattformen kompilieren, könnten sie zunächst die Variable ARCH=i386 für selbige Plattform einfügen und PROGNAME wie folgt setzen:

 PROGNAME=$PROGNAME-$VERSION-$ARCH-$BUILD

Nachdem nun eine Art Rahmen für das Package geschrieben wurde, sollten folgende weitere Punkte in Erfahrung gebracht werden:

Wie wird rxvt installiert? (Hier kommt der gewohnter Dreierschritt zum Einsatz: ./configure && make && make install)
Sind Parameter für den ./configure-Befehl, beispielsweise für einen anderen Prefix oder Zusatzfeatures, nötig? (Hinweis: Es ist gang und gäbe, daß bei Packages der Prefix /usr lautet und /usr/local nur bei "manuell" installierter Software verwendet wird.)
Die notwendigen Funktionen
Da normalweise keine besonderen Attribute oder sonstige spezielle Änderungen vorgenommen werden müssen entfallen schon attributes() und special(). Es werden insgesamt nur 4 Dateien installiert, daher besteht kein Sinn diese in Subpackages aufzuteilen, demnach kann auch auf subpacks() verzichtet werden.