PKGBUILD(5) Pacman-Handbuch PKGBUILD(5) BEZEICHNUNG PKGBUILD - Beschreibungsdatei fur den Bau von Archlinux-Paketen UBERSICHT PKGBUILD BESCHREIBUNG Dieses Handbuch beschreibt die allgemeinen Regeln zu den PKGBUILDs. Sobald ein PKGBUILD geschrieben ist, wird das eigentliche Paket mittels >>makepkg<< gebaut und mit Pacman installiert. Hinweis Einen beispielhaften PKGBUILD fur Referenzzwecke finden Sie in /usr/share/pacman zusammen mit weiteren Beispieldateien, wie einem Installationsskript. Sie konnen die dort verfugbare Datei PKGBUILD.proto in ein neues Paketbauverzeichnis kopieren und dort nach Ihren Wunschen anpassen. OPTIONEN UND ANWEISUNGEN Nachfolgend finden Sie eine Liste der Standardoptionen und -anweisungen, die in einem PKGBUILD verwendbar sind. Diese werden alle durch Makepkg verstanden und interpretiert. Die meisten davon werden direkt in das erstellte Paket ubertragen. Die zwingend erforderlichen Felder fur einen minimal funktionalen PKGBUILD sind pkgname, pkgver, pkgrel und arch. Wenn Sie benutzerdefinierte Variablen erstellen wollen, um diese im Bauprozess zu verwenden, wird empfohlen, deren Namen einen _ (Unterstrich) voranzustellen. Dadurch werden mogliche Namenskonflikte mit den internen Makepkg-Variablen vermieden. Um beispielsweise die Basisversion des Kernels in einer Variable zu speichern, konnten Sie etwas in der Form $_basekernver verwenden. pkgname (Feld) gibt entweder den Namen des Pakets oder ein Feld aus Namen fur geteilte Pakete an. Fur die Elemente des Feldes konnen Sie alphanumerische Zeichen sowie die folgenden Zeichen verwenden: >>@ . _ + -<<. Ausserdem durfen Namen nicht mit Bindestrichen oder Punkten beginnen. pkgver gibt die vom herausgebenden Autor festgelegte Version des Pakets an (beispielsweise 2.7.1). Die Variable darf keine Doppelpunkte, Schragstriche, Bindestriche oder Leerraume enthalten. Die Variable >>pkgver<< kann automatisch aktualisiert werden, indem Sie eine pkgver()-Funktion im PKGBUILD bereitstellen, welche die neue Paketversion ausgibt. Diese Funktion wird nach dem Herunterladen und Entpacken der Quellen und nachdem die prepare()-Funktion aufgerufen wurde (falls vorhanden) ausgefuhrt, so dass deren Dateien zur Ermittlung der neuen Paketversion (pkgver) verwendet werden konnen. Dies ist insbesondere nutzlich, wenn Sie Quellen aus Versionsverwaltungssystemen verwenden (siehe unten). pkgrel bezeichnet die distributionsbezogene Release-Nummer. Dadurch wird Paketbetreuern beispielsweise ermoglicht, die Configure-Schalter eines Pakets zu aktualisieren. Diese Nummer wird fur jede neue Upstream-Veroffentlichung ublicherweise auf 1 gesetzt und bei jedem zwischenzeitlich aktualisierten PKGBUILD erhoht. Die Variable ist eine positive Ganzzahl, wobei Sie fur jede Zwischenveroffentlichungsstufe eine weitere positive Ganzzahl hinzufugen konnen, durch einen Punkt getrennt (zum Beispiel in der Form x.y). epoch erzwingt, dass das Paket als neuer als alle vorherigen Versionen mit einer niedrigeren Epoche betrachtet wird, selbst wenn die Versionsnummer keine Aktualisierung auslosen wurde. Der Wert muss eine positive Ganzzahl sein, wenn nichts angegeben ist, wird 0 verwendet. Dies ist nutzlich, wenn sich das Versionierungsschema eines Pakets andert (oder alphanumerisch ist) und der normale Vergleich der Versionsmummern scheitern wurde. Siehe pacman(8) fur weitere Informationen zu Versionsvergleichen. pkgdesc sollte eine Kurzbeschreibung des Pakets und dessen Funktionalitat enthalten. Versuchen Sie, diese Beschreibung auf eine Zeile zu beschranken und den Namen des Pakets nicht zu nennen. url enthalt eine URL, die mit der paketierten Software korrespondiert. Dies ist typischerweise die Webseite des Projekts. license (Feld) legt die fur das Paket relevant(en) Lizenz(en) fest. Haufig verwendete Lizenzen finden Sie in /usr/share/licenses/common. Falls die Lizenz Ihres Pakets dort aufgefuhrt ist, konnen Sie im Lizenzfeld direkt darauf verweisen (zum Beispiel license=('GPL')). Falls das Paket unter die Bedingungen einer Lizenz fallt, die in /usr/share/licenses/common nicht enthalten ist, sollten Sie diese direkt im Paket mitliefern und license=('custom') oder license=('custom:LicenseName') verwenden. Die Lizenz sollte beim Bau des Pakets in $pkgdir/usr/share/licenses/$pkgname/ gespeichert werden. Wenn mehrere Lizenzen anwendbar sind, listen Sie sie alle auf: license=('GPL' 'FDL'). install gibt ein spezielles Installationsskript an, welches in das Paket einbezogen werden soll. Diese Datei sollte sich im gleichen Verzeichnis wie die Datei PKGBUILD befinden. Sie wird von Makepkg in das Paket kopiert. Sie muss nicht in das >>source<<-Feld einbezogen werden (zum Beispiel install=$pkgname.install). changelog gibt eine Anderungsprotokolldatei an, welche in das Paket einbezogen werden soll. Diese Datei sollte mit einem einzelnen Zeilenvorschub enden und sich im gleichen Verzeichnis wie die Datei PKGBUILD befinden und wird von Makepkg in das Paket kopiert. Sie muss nicht in das >>source<<-Feld einbezogen werden (zum Beispiel changelog=$pkgname.changelog). source (Feld) gibt ein Feld aus Quelldateien an, die zum Bau des Pakets erforderlich sind. Die Quelldateien mussen sich entweder im gleichen Verzeichnis wie die Datei PKGBUILD befinden oder als eine vollstandige URL angegeben werden, von wo sie Makepkg herunterladen kann. Um die Wartung der PKGBUILDs zu vereinfachen, verwenden Sie bei der Angabe des Orts zum Herunterladen die Variablen $pkgname und $pkgver, sofern moglich. Komprimierte Dateien werden automatisch entpackt, es sei denn, sie sind im nachfolgend beschriebenen >>noextract<<-Feld aufgelistet. Zusatzliche architekturspezifische Quellen konnen Sie hinzufugen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhangen, zum Beispiel source_x86_64=(). Ein korrespondierendes Integritatsfeld mit Prufsummen muss vorhanden sein, zum Beispiel cksums_x86_64=(). Es ist ausserdem moglich, den Namen der heruntergeladenen Datei zu andern, was insbesondere bei seltsamen URLs und fur den Umgang mit mehreren Quelldateien gleichen Namens nutzlich ist. Die Syntax ist: source=('Dateiname::URL'). Makepkg unterstutzt auch den Bau von Paketen fur Entwicklerversionen mittels Herunterladen der Quellen aus Versionsverwaltungssystemen (VCS). Weitere Informationen finden Sie im nachfolgenden Abschnitt >>Quellen aus Versionsverwaltungssystemen verwenden<<. Dateien im >>source<<-Feld mit den Endungen .sig, .sign oder .asc werden von Makepkg als PGP-Signaturen erkannt und automatisch zur Uberprufung der Integritat der korrespondierenden Quelldatei verwendet. validpgpkeys (Feld) gibt ein Feld aus PGP-Fingerabdrucken an. Wenn dieses Feld nicht leer ist, wird Makepkg nur Signaturen von Schlusseln akzeptieren, die hier aufgelistet sind und ausserdem die Vertrauenswerte im Schlusselbund ignorieren. Falls die Quelldatei mit einem Unterschlussel signiert wurde, verwendet Makepkg dennoch den primaren Schlussel fur den Vergleich. Es werden nur vollstandige Fingerabdrucke akzeptiert. Diese mussen in Grossschreibung vorliegen und durfen keine Leerraume enthalten. noextract (Feld) gibt ein Feld aus Dateinamen an, die denen aus dem >>source<<-Feld entsprechen. Die hier aufgelisteten Dateien werden nicht zusammen mit dem Rest der Quelldateien entpackt. Dies ist fur Pakete hilfreich, die komprimierte Daten direkt verwenden. cksums (Feld) Dieses Feld enthalt CRC-Prufsummen fur jede im >>source<<-Feld angegebene Quelldatei (in der gleichen Reihenfolge). Makepkg verwendet diese zur Uberprufung der Dateiintegritat bei anschliessenden Bauvorgangen. Wenn anstelle einer normalen Prufsumme SKIP im Feld steht, wird die Integritatsprufung fur die betreffende Quelldatei ubersprungen. Um cksums (Prufsummen) einfach zu erzeugen, verwenden Sie den Befehl >>makepkg -g >> PKGBUILD<<. Falls gewunscht, konnen Sie die cksums-Zeile an eine geeignete Stelle verschieben. Beachten Sie, dass die mit >>makepkg -g<< erzeugten Prufsummen anhand der von den Software-Entwicklern bereitgestellten Prufsummenwerte verifiziert werden sollten. md5sums, sha1sums, sha224sums, sha256sums, sha384sums, sha512sums, b2sums (Felder) gibt alternative Integritatsprufungen an, die Makepkg unterstutzt. Diese verhalten sich alle ahnlich zu der oben beschriebenen cksums-Option. Um die Verwendung und Erzeugung dieser Prufsummen zu aktivieren, stellen Sie sicher, dass die Option INTEGRITY_CHECK in makepkg.conf(5) konfiguriert ist. groups (Feld) Ein Feld aus symbolischen Namen, die Paketgruppen reprasentieren. Damit konnen Sie mehrere Pakete durch Angabe eines einzelnen Ziels installieren. Zum Beispiel konnen Sie alle KDE-Pakete uber die Gruppe kde installieren. arch (Feld) legt fest, auf welchen Architekturen das angegebene Paket verfugbar ist (zum Beispiel arch=('i686' 'x86_64')). Pakete, die keine architekturspezifischen Dateien enthalten, sollten arch=('any') verwenden. Sie konnen fur die Angabe alphanumerische Zeichen und den Unterstrich >>_<< verwenden. backup (Feld) Ein Feld aus Namen der Dateien (ohne vorangestellte Schragstriche), die gesichert werden sollen, wenn das Paket entfernt oder aktualisiert wird. Dies wird haufig fur Pakete verwendet, die Konfigurationsdateien in /etc ablegen. Siehe >>Umgang mit Konfigurationsdateien<< in pacman(8) fur weitere Informationen. depends (Feld) Ein Feld aus Paketen, von denen dieses Paket fur die Ausfuhrung abhangig ist. Die Eintrage in dieser Liste sollten in einfache Hochkommata eingeschlossen werden und mindestens einen Paketnamen enthalten. Die Eintrage konnen ausserdem eine Versionsangabe der Form Name<>version enthalten, wobei <> einer von funf Vergleichsoperatoren ist: >= (grosser oder gleich), <= (kleiner oder gleich), = (gleich), > (grosser als) oder < (kleiner als). Falls der Abhangigkeitsname auf eine Bibliothek hindeutet (endet mit .so), versucht Makepkg ein Programm zu finden, das von der Bibliothek im gebauten Paket abhangt und hangt die vom Programm benotigte Version an. Wenn Sie die Version selbst anhangen, wird dadurch die automatische Erkennung ubersprungen. Zusatzliche architekturspezifische Abhangigkeiten konnen Sie hinzufugen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhangen, zum Beispiel depends_x86_64=(). makedepends (Feld) Ein Feld aus Paketen, welche dieses Paket zum Bau benotigt, die aber wahrend der Laufzeit nicht erforderlich sind. Die Pakete in dieser Liste folgen dem gleichen Schema wie jene in >>depends<<. Weitere archtekturabhangige Bau-Abhangigkeiten konnen Sie angeben, indem Sie einen Unterstrich und den Namen der Architektur anhangen, zum Beispiel makedepends_x86_64=(). checkdepends (Feld) Ein Feld aus Paketen, welche dieses Paket zum Ausfuhren der Tests benotigt, die aber wahrend der Laufzeit nicht erforderlich sind. Die Pakete in dieser Liste folgen dem gleichen Schema wie jene in >>depends<<. Diese Abhangigkeiten werden nur beachtet, wenn die check()-Funktion vorhanden ist und von Makepkg ausgefuhrt wird. Zusatzliche architekturspezifische >>checkdepends<<-Abhangigkeiten konnen Sie hinzufugen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhangen, zum Beispiel checkdepends_x86_64=(). optdepends (Feld) Ein Feld aus Paketen (und begleitenden Erklarungen), die fur die Basisfunktionalitat nicht entscheidend sind, aber fur die vollstandige Funktionalitat des Paketinhalts notwendig sein konnten. Die >>optdepends<< dienen gegenwartig nur informativen Zwecken und werden von Pacman bei der Abhangigkeitsauflosung nicht berucksichtigt. Die Pakete in dieser Liste folgen dem gleichen Format wie >>depends<<, mit einer optionalen angehangten Beschreibung. Die Beschreibungen der >>optdepends<< mussen in folgendem Format angegeben werden: optdepends=('python: for library bindings') Zusatzliche architekturspezifische >>optdepends<<-Abhangigkeiten konnen Sie hinzufugen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhangen, zum Beispiel optdepends_x86_64=(). conflicts (Feld) Ein Feld aus Paketen, die zu diesem Paket in Konflikt stehen (was bedeutet, dass sie nicht gleichzeitig installiert werden konnen). Die Anweisung folgt dem gleichen Schema wie jene in >>depends<<. Die Angabe von Versionsnummern ist hier moglich, wenn Sie die in >>depends<< beschriebenen Operatoren verwenden. Zusatzliche architekturspezifische Konflikte konnen Sie hinzufugen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhangen, zum Beispiel conflicts_x86_64=(). provides (Feld) Ein Feld aus >>virtuellen Bereitstellungen<< dieses Pakets. Dadurch wird es moglich, dass ein Paket Abhangigkeiten fur andere Pakete bereitstellt, die uber dessen eigenen Namen hinausgehen. Beispielsweise kann das Paket >>dcron<< zusatzlich cron bereitstellen, wodurch Pakete von cron abhangen konnen und nicht von dcron ODER fcron. Die Versionierung der virtuellen Bereitstellung ist im Format Name=Version moglich. Beispielsweise kann >>dcron<< ausserdem cron=2.0 bereitstellen, um die Abhangigkeit anderer Pakete zu cron>=2.0 zu erfullen. Bereitstellungen, welche die Operatoren > und < enthalten, sind unzulassig, weil nur spezifische Versionen eines Pakets bereitgestellt werden. Falls der Name einer Bereitstellung eine Bibliothek zu sein scheint (endet auf .so), versucht Makepkg die Bibliothek im Paket zu finden und die korrekte Version anzuhangen. Wenn Sie die Version selbst anhangen, schaltet dies die automatische Erkennung aus. Zusatzliche architekturspezifische Bereitstellungen konnen Sie hinzufugen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhangen, zum Beispiel provides_x86_64=(). replaces (Feld) Ein Feld aus Paketen, welche dieses Paket ersetzt. Dies kann dazu dienen, umbenannte oder zusammengefasste Pakete zu verarbeiten. Wenn beispielsweise das Paket j2re in jre umbenannt wurde, dann ermoglicht diese Anweisung zukunftige reibungslose Aktualisierungen, obwohl das Paket >>umgezogen<< ist. Die Angabe von Versionsnummern ist hier moglich, wenn Sie die in >>depends<< beschriebenen Operatoren verwenden. Eine Systemaktualisierung ist derzeit der einzige Vorgang, bei dem Pacman dieses Feld berucksichtigt. Eine normale Synchronisation oder Aktualisierung verwendet dessen Wert nicht. Zusatzliche architekturspezifische Ersetzungen konnen Sie hinzufugen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhangen, zum Beispiel replaces_x86_64=(). options (Feld) Dieses Feld ermoglicht Ihnen, einige Aspekte des voreingestellten Verhaltens von Makepkg ausser Kraft zu setzen, wenn Sie Pakete bauen. Um eine Option festzulegen, setzen Sie deren Namen einfach in das Optionsfeld. Um zum Standardverhalten zuruckzukehren, setzen Sie ein Ausrufezeichen vor die Option. Geben Sie nur die spezifischen Optionen an, die Sie ausser Kraft setzen wollen, der Rest wird aus makepkg.conf(5) ubernommen. HINWEIS: Die Option force wurde entfernt und deren Wirkung durch die Variable epoch auf der obersten Ebene ersetzt. strip Entfernt Symbole aus Programmen und Bibliotheken. Wenn Sie haufig einen Debugger bei Programmen oder Bibliotheken verwenden, kann es hilfreich sein, diese Option zu deaktivieren. docs speichert die Dokumentationsverzeichnisse. Wenn Sie die Dokumentationsverzeichnisse loschen wollen, geben Sie >>!docs<< im Feld an. libtool Belasst Libtool-Dateien (.la) in Paketen. Geben Sie !libtool an, um diese zu entfernen. staticlibs Belasst statische Bibliotheksdateien (.a) in Paketen Geben Sie !staticlibs an, um diese zu entfernen (sofern es ein dynamisch gelinktes Gegenstuck gibt). emptydirs belasst leere Verzeichnisse in Paketen. zipman komprimiert Handbuchseiten (man und info) mit gzip. ccache ermoglicht die Nutzung von Ccache wahrend des Bauvorgangs mit build(). Dies ist in der negierten Form >>!ccache<< am nutzlichsten, wenn bestimmte Pakete Probleme beim Bau mit Ccache haben. distcc ermoglicht die Nutzung von Distcc wahrend des Bauvorgangs mit build(). Dies ist in der negierten Form >>!distcc<< am nutzlichsten, wenn bestimmte Pakete Probleme beim Bau mit Distcc haben. buildflags ermoglicht die Nutzung benutzerdefinierter Buildflags (CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS) wahrend des Bauvorgangs mit build(), wie in makepkg.conf(5) angegeben. Dies ist in der negierten Form >>!buildflags<< am nutzlichsten, wenn bestimmte Pakete Probleme beim Bau mit benutzerdefinierten Buildflags haben. makeflags ermoglicht die Nutzung benutzerdefinierter Makeflags wahrend des Bauvorgangs mit build(), wie in makepkg.conf(5) angegeben. Dies ist in der negierten Form >>!makeflags<< am nutzlichsten, wenn bestimmte Pakete Probleme beim Bau mit benutzerdefinierten Makeflags haben, wie -j2 (oder hoher). debug fugt die benutzerdefinierten Debug-Flags (DEBUG_CFLAGS, DEBUG_CXXFLAGS) zu den korrespondierenden Buildflags hinzu, wie in makepkg.conf(5) angegeben. Wird dies in Verbindung mit der Option >>strip<< verwendet, wird ein separates Paket erstellt, das die Debug-Symbole enthalt. lto aktiviert den Paketbau mittels Linkzeit-Optimierung. Fugt -flto zu CFLAGS und CXXFLAGS hinzu . PAKETIERUNGSFUNKTIONEN Ausser den oben genannten Anweisungen benotigen PKGBUILDs eine Reihe von Funktionen, die Anweisungen zum Bau und zur Installation des Pakets bereitstellen. Als Minimum muss ein PKGBUILD eine package()-Funktion enthalten, welche alle Dateien des Pakets in das Paketierungsverzeichnis installiert. Hinzu kommen optional die Funktionen prepare(), build() und check(), die zur Erstellung dieser Dateien aus den Quellen dienen. Dies wird direkt durch Makepkg ausgewertet und ausgefuhrt, so dass Sie hier alles verwenden konnen, was die Bash oder das System versteht. Stellen Sie sicher, dass eventuelle exotische Befehle durch die Abhangigkeiten im >>makedepends<<-Feld zur Verfugung gestellt werden. Falls Sie in einer dieser Funktionen eigene Variablen definieren, ist es empfehlenswert, diese mit dem Bash-Schlusselwort >>local<< auf den Bereich innerhalb der jeweiligen Funktion zu beschranken. package()-Funktion Die package()-Funktion wird zum Installieren von Dateien in das Verzeichnis verwendet, das zum Wurzelverzeichnis des gebauten Pakets wird. Sie wird nach allen nachfolgend beschriebenen optionalen Funktionen ausgefuhrt. Die Paketierungsstufe wird in einer Fakeroot-Umgebung ausgefuhrt, um die korrekten Zugriffsrechte des sich ergebenden Pakets sicherzustellen. Alle anderen Funktionen laufen unter der Kennung und mit den gleichen Rechten wie der Benutzer, der Makepkg ausfuhrt.. prepare()-Funktion Eine optionale prepare()-Funktion kann angegeben werden, in der die Quellen fur den Bau vorbereitet werden, zum Beispiel durch Patchen. Diese Funktion wird nach dem Entpacken der Quellen und vor der build()-Funktion ausgefuhrt. Die prepare()-Funktion wird ubersprungen, wenn das Entpacken der Quellen ubersprungen wird. build()-Funktion Die optionale >>build()<<-Funktion wird zum Kompilieren und/oder Anpassen der Quelldateien verwendet, um diese fur die Installation durch die >>package()<<-Funktion vorzubereiten. check()-Funktion Eine optionale check()-Funktion kann angegeben werden, welche die Testsuite eines Pakets ausfuhrt. Diese Funktion wird zwischen den Funktionen build() und package() ausgefuhrt. Stellen Sie sicher, dass eventuelle exotische Befehle durch die Abhangigkeiten im >>makedepends<<-Feld zur Verfugung gestellt werden. Alle der oben genannten Variablen wie $pkgname und $pkgver konnen in den Paketierungsfunktionen verwendet werden. Zusatzlich definiert Makepkg die folgenden Variablen: srcdir gibt das Verzeichnis an, in das Makepkg alle Quelldateien entpackt bzw. kopiert. Alle der oben definierten Paketierungsfunktionen werden im Verzeichnis $srcdir ausgefuhrt. pkgdir gibt das Verzeichnis an, in dem Makepkg das installierte Paket zusammenstellt. Dieses Verzeichnis wird zum Wurzelverzeichnis Ihres gebauten Pakets. Diese Variable sollte ausschliesslich in der package()-Funktion verwendet werden. startdir gibt den absoluten Pfad zu dem Verzeichnis an, in dem sich die Datei PKGBUILD befindet. Dies ist typischerweise die Ausgabe des Befehls $(pwd), wenn Makepkg gestartet ist. Die Verwendung dieser Variable ist veraltet, wir raten strikt davon ab. TEILEN VON PAKETEN Makepkg unterstutzt den Bau mehrerer Pakete aus einem einzigen PKGBUILD. Dafur wird der >>pkgname<<-Anweisung ein Feld von Paketnamen zugewiesen. Jedes Teilpaket verwendet eine korrespondierende Paketierungsfunktion mit dem Namen package_foo(), wobei >>foo<< der Name des Teilpakets ist. Alle Optionen und Anweisungen fur die Teilpakete verwenden in der Voreinstellung die im PKGBUILD angegebenen globalen Werte. Dennoch konnen Sie die folgenden innerhalb der Paketierungsfunktion jedes Teilpakets ausser Kraft setzen: pkgdesc, arch, url, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options, install und changelog. Beachten Sie, dass Makepkg die Abhangigkeiten der Teilpakete nicht berucksichtigt, wenn die Abhangigkeitsauflosung vor dem Bau des Pakets und mit --syncdeps erfolgt. Alle fur den Bau des Pakets benotigten Pakete mussen in den globalen >>depends<<- und >>makedepends<<-Feldern angegeben werden. Eine optionale globale Anweisung ist beim Bau eines geteilten Pakets verfugbar: pkgbase Dies ist der Name, der bei Bezugen in der Ausgabe von Makepkg auf die Paketgruppe und in der Benennung von reinen Quellen-Tarballs verwendet wird. Wenn nichts angegeben ist, wird das erste Element im >>pkgname<<-Feld verwendet. Fur diese Variable sind alphanumerische Zeichen sowie die Zeichen >>@<<, >>.<<, >>_<<, >>+<< und >>-<< zulassig. Ausserdem darf der Variablenname nicht mit Bindestrichen oder Punkten beginnen. SKRIPTE ZUM INSTALLIEREN/AKTUALISIEREN/ENTFERNEN Pacman kann beim Installieren, Entfernen oder Aktualisieren eines Pakets ein paketspezifisches Skript speichern und ausfuhren. Dadurch kann sich ein Paket nach der Installation selbst konfigurieren und beim Entfernen den umgekehrten Vorgang ausfuhren. Der exakte Zeitpunkt der Ausfuhrung des Skripts ist von der jeweiligen Operation abhangig und sollte selbsterklarend sein. Beachten Sie, dass wahrend einer Aktualisierungsoperation keine der Installations- oder Entfernungsfunktionen aufgerufen wird. Den Skripten werden entweder eine oder zwei >>vollstandige Versionszeichenketten<< ubergeben, wobei eine vollstandige Versionszeichenkette entweder pkgver-pkgrel oder epoch:pkgver-pkgrel lautet, falls >>epoch<< nicht Null ist. pre_install wird unmittelbar vor dem Entpacken der Dateien ausgefuhrt. Ein Argument wird ubergeben: die vollstandige Versionszeichenkette des neuen Pakets. post_install wird unmittelbar vor dem Entpacken der Dateien ausgefuhrt. Ein Argument wird ubergeben: die vollstandige Versionszeichenkette des neuen Pakets. pre_upgrade wird unmittelbar vor dem Entpacken der Dateien ausgefuhrt. Zwei Argumente werden in folgender Reihenfolge ubergeben: die vollstandige Versionszeichenkette des neuen Pakets und die vollstandige Versionszeichenkette des alten Pakets. post_upgrade wird nach dem Entpacken der Dateien ausgefuhrt. Zwei Argumente werden in folgender Reihenfolge ubergeben: die vollstandige Versionszeichenkette des neuen Pakets und die vollstandige Versionszeichenkette des alten Pakets. pre_remove wird unmittelbar vor dem Entfernen der Dateien ausgefuhrt. Ein Argument wird ubergeben: die vollstandige Versionszeichenkette des alten Pakets. post_remove wird unmittelbar nach dem Entfernen der Dateien ausgefuhrt. Ein Argument wird ubergeben: die vollstandige Versionszeichenkette des alten Pakets. Um dieses Funktionsmerkmal zu nutzen, legen Sie eine Datei namens Paketname.install an und speichern Sie sie im gleichen Verzeichnis wie das PKGBUILD-Skript. Dann verwenden Sie folgende Installationsanweisung: install=Paketname.install Das Installationsskript muss im >>source<<-Feld nicht angegeben werden. Eine Vorlage fur eine solche Installationsdatei finden Sie in /usr/share/pacman als proto.install. Sie referenziert alle verfugbaren definierten Funktionen. QUELLEN AUS VERSIONSVERWALTUNGSSYSTEMEN VERWENDEN Sie konnen den Bau eines Pakets aus einem Versionsverwaltungssystem (VCS) aktivieren, indem Sie die Quelle in der folgenden Form angeben: source=('Verzeichnis::URL#Fragment?Abfrage') Gegenwartig unterstutzt Makepkg die Versionsverwaltungssysteme Bazaar, Git, Subversion, Fossil und Mercurial. Fur andere Versionsverwaltungssysteme mussen Sie das Klonen des Upstream-Repositoriums manuell in der prepare()-Funktion ausfuhren. Die Quellen-URL besteht aus vier Komponenten: Verzeichnis (optional) Gibt den Namen eines alternativen Verzeichnisses an, in das Makepkg die VCS-Quellen herunterladen soll. url gibt die URL des VCS-Repositoriums an. Diese muss das VCS im URL-Protokoll enthalten, damit Makepkg sie als VCS-Quelle erkennt. Falls das Protokoll den VCS-Namen nicht enthalt, konnen Sie ihn hinzufugen, indem Sie vcs+ der URL voranstellen. Wenn Sie beispielsweise ein Git-Repositorium uber HTTPS verwenden, wurde eine Quellen-URL folgende Form haben: git+https://. Fragment (optional) Erlaubt die Angabe einer Revisionsnummer oder eines Zweiges, die oder den Makepkg aus dem VCS auschecken soll. Ein Fragment hat die Form Typ=Wert; um beispielsweise eine gegebene Revision auszuchecken, wurde die Quellen-Zeile source=(URL#Revision=123) lauten. Die verfugbaren Typen sind vom verwendeten VCS abhangig: bzr revision (siehe 'bzr help revisionspec' fur Details) fossil branch, commit, tag git branch, commit, tag hg branch, revision, tag svn revision query (optional) Erlaubt die Angabe, ob ein VCS-Checkout auf PGP-signierte Revisionen untersucht werden soll. Die Quellen-Zeile sollte im Format source=(URL#Fragment?signed) oder source=(URL?signed#Fragment) sein. Gegenwartig wird dies nur von Git unterstutzt. BEISPIEL Nachfolgend sehen Sie ein Beispiel-PKGBUILD fur das Paket patch. Weitere Beispiele finden Sie in den Bauskripten der Pakete Ihrer Distribution. Nutzer von Archlinux sollten sich das Arch Build System (ABS) anschauen. # Maintainer: Joe User pkgname=patch pkgver=2.7.1 pkgrel=1 pkgdesc="A utility to apply patch files to original sources" arch=('i686' 'x86_64') url="https://www.gnu.org/software/patch/patch.html" license=('GPL') groups=('base-devel') depends=('glibc') makedepends=('ed') optdepends=('ed: for "patch -e" functionality') source=("ftp://ftp.gnu.org/gnu/$pkgname/$pkgname-$pkgver.tar.xz"{,.sig}) md5sums=('e9ae5393426d3ad783a300a338c09b72' 'SKIP') build() { cd "$srcdir/$pkgname-$pkgver" ./configure --prefix=/usr make } package() { cd "$srcdir/$pkgname-$pkgver" make DESTDIR="$pkgdir/" install } SIEHE AUCH makepkg(8), pacman(8), makepkg.conf(5) Auf der Pacman-Website finden Sie aktuelle Informationen zu Pacman und den zugehorigen Werkzeugen. FEHLER Fehler? Sie machen wohl Witze, es gibt keine Fehler in dieser Software. Nun ja, sollte unsere Annahme doch falsch sein, senden Sie uns einen Fehlerbericht (auf Englisch) mit so vielen Details wie moglich in der Fehlerdatenbank von Archlinux im Bereich >>Pacman<<. AUTOREN Derzeitige Betreuer: o Allan McRae o Andrew Gregory o Eli Schwartz o Morgan Adamiec Bedeutende fruhere Mitwirkende: o Judd Vinet o Aurelien Foret o Aaron Griffin o Dan McGee o Xavier Chantry o Nagy Gabor o Dave Reisner Informationen zu weiteren Mitwirkenden erhalten Sie, wenn Sie den Befehl git shortlog -s im Git-Repositorium pacman.git aufrufen. UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Mario Blattermann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . Pacman 6.0.2 6. Februar 2024 PKGBUILD(5)