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.