PKGBUILD(5) Pacman-Handbuch PKGBUILD(5)

PKGBUILD - Beschreibungsdatei für den Bau von Archlinux-Paketen

ÜBERSICHT

PKGBUILD

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 für Referenzzwecke finden Sie in /usr/share/pacman zusammen mit weiteren Beispieldateien, wie einem Installationsskript. Sie können die dort verfügbare Datei PKGBUILD.proto in ein neues Paketbauverzeichnis kopieren und dort nach Ihren Wünschen anpassen.

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 übertragen. Die zwingend erforderlichen Felder für 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 mögliche Namenskonflikte mit den internen Makepkg-Variablen vermieden. Um beispielsweise die Basisversion des Kernels in einer Variable zu speichern, könnten Sie etwas in der Form $_basekernver verwenden.

pkgname (Feld)

gibt entweder den Namen des Pakets oder ein Feld aus Namen für geteilte Pakete an. Für die Elemente des Feldes können Sie alphanumerische Zeichen sowie die folgenden Zeichen verwenden: »@ . _ + -«. Außerdem dürfen 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, Schrägstriche, Bindestriche oder Leerräume 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) ausgeführt, so dass deren Dateien zur Ermittlung der neuen Paketversion (pkgver) verwendet werden können. Dies ist insbesondere nützlich, wenn Sie Quellen aus Versionsverwaltungssystemen verwenden (siehe unten).

pkgrel

bezeichnet die distributionsbezogene Release-Nummer. Dadurch wird Paketbetreuern beispielsweise ermöglicht, die Configure-Schalter eines Pakets zu aktualisieren. Diese Nummer wird für jede neue Upstream-Veröffentlichung üblicherweise auf 1 gesetzt und bei jedem zwischenzeitlich aktualisierten PKGBUILD erhöht. Die Variable ist eine positive Ganzzahl, wobei Sie für jede Zwischenveröffentlichungsstufe eine weitere positive Ganzzahl hinzufügen können, 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 auslösen würde. Der Wert muss eine positive Ganzzahl sein, wenn nichts angegeben ist, wird 0 verwendet. Dies ist nützlich, wenn sich das Versionierungsschema eines Pakets ändert (oder alphanumerisch ist) und der normale Vergleich der Versionsmummern scheitern würde. Siehe pacman(8) für weitere Informationen zu Versionsvergleichen.

pkgdesc

sollte eine Kurzbeschreibung des Pakets und dessen Funktionalität enthalten. Versuchen Sie, diese Beschreibung auf eine Zeile zu beschränken und den Namen des Pakets nicht zu nennen.

url

enthält eine URL, die mit der paketierten Software korrespondiert. Dies ist typischerweise die Webseite des Projekts.

license (Feld)

legt die für das Paket relevant(en) Lizenz(en) fest. Häufig verwendete Lizenzen finden Sie in /usr/share/licenses/common. Falls die Lizenz Ihres Pakets dort aufgeführt ist, können Sie im Lizenzfeld direkt darauf verweisen (zum Beispiel license=('GPL')). Falls das Paket unter die Bedingungen einer Lizenz fällt, 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 Änderungsprotokolldatei 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 müssen sich entweder im gleichen Verzeichnis wie die Datei PKGBUILD befinden oder als eine vollständige 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 möglich. Komprimierte Dateien werden automatisch entpackt, es sei denn, sie sind im nachfolgend beschriebenen »noextract«-Feld aufgelistet.

Zusätzliche architekturspezifische Quellen können Sie hinzufügen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhängen, zum Beispiel source_x86_64=(). Ein korrespondierendes Integritätsfeld mit Prüfsummen muss vorhanden sein, zum Beispiel cksums_x86_64=().

Es ist außerdem möglich, den Namen der heruntergeladenen Datei zu ändern, was insbesondere bei seltsamen URLs und für den Umgang mit mehreren Quelldateien gleichen Namens nützlich ist. Die Syntax ist: source=('Dateiname::URL').

Makepkg unterstützt auch den Bau von Paketen für 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 Überprüfung der Integrität der korrespondierenden Quelldatei verwendet.

validpgpkeys (Feld)

gibt ein Feld aus PGP-Fingerabdrücken an. Wenn dieses Feld nicht leer ist, wird Makepkg nur Signaturen von Schlüsseln akzeptieren, die hier aufgelistet sind und außerdem die Vertrauenswerte im Schlüsselbund ignorieren. Falls die Quelldatei mit einem Unterschlüssel signiert wurde, verwendet Makepkg dennoch den primären Schlüssel für den Vergleich.

Es werden nur vollständige Fingerabdrücke akzeptiert. Diese müssen in Großschreibung vorliegen und dürfen keine Leerräume 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 für Pakete hilfreich, die komprimierte Daten direkt verwenden.

cksums (Feld)

Dieses Feld enthält CRC-Prüfsummen für jede im »source«-Feld angegebene Quelldatei (in der gleichen Reihenfolge). Makepkg verwendet diese zur Überprüfung der Dateiintegrität bei anschließenden Bauvorgängen. Wenn anstelle einer normalen Prüfsumme SKIP im Feld steht, wird die Integritätsprüfung für die betreffende Quelldatei übersprungen. Um cksums (Prüfsummen) einfach zu erzeugen, verwenden Sie den Befehl »makepkg -g >> PKGBUILD«. Falls gewünscht, können Sie die cksums-Zeile an eine geeignete Stelle verschieben. Beachten Sie, dass die mit »makepkg -g« erzeugten Prüfsummen anhand der von den Software-Entwicklern bereitgestellten Prüfsummenwerte verifiziert werden sollten.

md5sums, sha1sums, sha224sums, sha256sums, sha384sums, sha512sums, b2sums (Felder)

gibt alternative Integritätsprüfungen an, die Makepkg unterstützt. Diese verhalten sich alle ähnlich zu der oben beschriebenen cksums-Option. Um die Verwendung und Erzeugung dieser Prüfsummen 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 repräsentieren. Damit können Sie mehrere Pakete durch Angabe eines einzelnen Ziels installieren. Zum Beispiel können Sie alle KDE-Pakete über die Gruppe kde installieren.

arch (Feld)

legt fest, auf welchen Architekturen das angegebene Paket verfügbar ist (zum Beispiel arch=('i686' 'x86_64')). Pakete, die keine architekturspezifischen Dateien enthalten, sollten arch=('any') verwenden. Sie können für die Angabe alphanumerische Zeichen und den Unterstrich »_« verwenden.

backup (Feld)

Ein Feld aus Namen der Dateien (ohne vorangestellte Schrägstriche), die gesichert werden sollen, wenn das Paket entfernt oder aktualisiert wird. Dies wird häufig für Pakete verwendet, die Konfigurationsdateien in /etc ablegen. Siehe »Umgang mit Konfigurationsdateien« in pacman(8) für weitere Informationen.

depends (Feld)

Ein Feld aus Paketen, von denen dieses Paket für die Ausführung abhängig ist. Die Einträge in dieser Liste sollten in einfache Hochkommata eingeschlossen werden und mindestens einen Paketnamen enthalten. Die Einträge können außerdem eine Versionsangabe der Form Name<>version enthalten, wobei <> einer von fünf Vergleichsoperatoren ist: >= (größer oder gleich), <= (kleiner oder gleich), = (gleich), > (größer als) oder < (kleiner als).

Falls der Abhängigkeitsname auf eine Bibliothek hindeutet (endet mit .so), versucht Makepkg ein Programm zu finden, das von der Bibliothek im gebauten Paket abhängt und hängt die vom Programm benötigte Version an. Wenn Sie die Version selbst anhängen, wird dadurch die automatische Erkennung übersprungen.

Zusätzliche architekturspezifische Abhängigkeiten können Sie hinzufügen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhängen, zum Beispiel depends_x86_64=().

makedepends (Feld)

Ein Feld aus Paketen, welche dieses Paket zum Bau benötigt, die aber während der Laufzeit nicht erforderlich sind. Die Pakete in dieser Liste folgen dem gleichen Schema wie jene in »depends«.

Weitere archtekturabhängige Bau-Abhängigkeiten können Sie angeben, indem Sie einen Unterstrich und den Namen der Architektur anhängen, zum Beispiel makedepends_x86_64=().

checkdepends (Feld)

Ein Feld aus Paketen, welche dieses Paket zum Ausführen der Tests benötigt, die aber während der Laufzeit nicht erforderlich sind. Die Pakete in dieser Liste folgen dem gleichen Schema wie jene in »depends«. Diese Abhängigkeiten werden nur beachtet, wenn die check()-Funktion vorhanden ist und von Makepkg ausgeführt wird.

Zusätzliche architekturspezifische »checkdepends«-Abhängigkeiten können Sie hinzufügen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhängen, zum Beispiel checkdepends_x86_64=().

optdepends (Feld)

Ein Feld aus Paketen (und begleitenden Erklärungen), die für die Basisfunktionalität nicht entscheidend sind, aber für die vollständige Funktionalität des Paketinhalts notwendig sein könnten. Die »optdepends« dienen gegenwärtig nur informativen Zwecken und werden von Pacman bei der Abhängigkeitsauflösung nicht berücksichtigt. Die Pakete in dieser Liste folgen dem gleichen Format wie »depends«, mit einer optionalen angehängten Beschreibung. Die Beschreibungen der »optdepends« müssen in folgendem Format angegeben werden: 
optdepends=('python: for library bindings')

Zusätzliche architekturspezifische »optdepends«-Abhängigkeiten können Sie hinzufügen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhängen, 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 können). Die Anweisung folgt dem gleichen Schema wie jene in »depends«. Die Angabe von Versionsnummern ist hier möglich, wenn Sie die in »depends« beschriebenen Operatoren verwenden.

Zusätzliche architekturspezifische Konflikte können Sie hinzufügen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhängen, zum Beispiel conflicts_x86_64=().

provides (Feld)

Ein Feld aus »virtuellen Bereitstellungen« dieses Pakets. Dadurch wird es möglich, dass ein Paket Abhängigkeiten für andere Pakete bereitstellt, die über dessen eigenen Namen hinausgehen. Beispielsweise kann das Paket »dcron« zusätzlich cron bereitstellen, wodurch Pakete von cron abhängen können und nicht von dcron ODER fcron.

Die Versionierung der virtuellen Bereitstellung ist im Format Name=Version möglich. Beispielsweise kann »dcron« außerdem cron=2.0 bereitstellen, um die Abhängigkeit anderer Pakete zu cron>=2.0 zu erfüllen. Bereitstellungen, welche die Operatoren > und < enthalten, sind unzulässig, 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 anzuhängen. Wenn Sie die Version selbst anhängen, schaltet dies die automatische Erkennung aus.

Zusätzliche architekturspezifische Bereitstellungen können Sie hinzufügen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhängen, 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 ermöglicht diese Anweisung zukünftige reibungslose Aktualisierungen, obwohl das Paket »umgezogen« ist. Die Angabe von Versionsnummern ist hier möglich, wenn Sie die in »depends« beschriebenen Operatoren verwenden.

Eine Systemaktualisierung ist derzeit der einzige Vorgang, bei dem Pacman dieses Feld berücksichtigt. Eine normale Synchronisation oder Aktualisierung verwendet dessen Wert nicht.

Zusätzliche architekturspezifische Ersetzungen können Sie hinzufügen, indem Sie ihnen einen Unterstrich und den Architekturnamen anhängen, zum Beispiel replaces_x86_64=().

options (Feld)

Dieses Feld ermöglicht Ihnen, einige Aspekte des voreingestellten Verhaltens von Makepkg außer Kraft zu setzen, wenn Sie Pakete bauen. Um eine Option festzulegen, setzen Sie deren Namen einfach in das Optionsfeld. Um zum Standardverhalten zurückzukehren, setzen Sie ein Ausrufezeichen vor die Option. Geben Sie nur die spezifischen Optionen an, die Sie außer Kraft setzen wollen, der Rest wird aus makepkg.conf(5) übernommen. 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 häufig einen Debugger bei Programmen oder Bibliotheken verwenden, kann es hilfreich sein, diese Option zu deaktivieren.

docs

speichert die Dokumentationsverzeichnisse. Wenn Sie die Dokumentationsverzeichnisse löschen wollen, geben Sie »!docs« im Feld an.

libtool

Belässt Libtool-Dateien (.la) in Paketen. Geben Sie !libtool an, um diese zu entfernen.

staticlibs

Belässt statische Bibliotheksdateien (.a) in Paketen Geben Sie !staticlibs an, um diese zu entfernen (sofern es ein dynamisch gelinktes Gegenstück gibt).

emptydirs

belässt leere Verzeichnisse in Paketen.

zipman

komprimiert Handbuchseiten (man und info) mit gzip.

ccache

ermöglicht die Nutzung von Ccache während des Bauvorgangs mit build(). Dies ist in der negierten Form »!ccache« am nützlichsten, wenn bestimmte Pakete Probleme beim Bau mit Ccache haben.

distcc

ermöglicht die Nutzung von Distcc während des Bauvorgangs mit build(). Dies ist in der negierten Form »!distcc« am nützlichsten, wenn bestimmte Pakete Probleme beim Bau mit Distcc haben.

buildflags

ermöglicht die Nutzung benutzerdefinierter Buildflags (CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS) während des Bauvorgangs mit build(), wie in makepkg.conf(5) angegeben. Dies ist in der negierten Form »!buildflags« am nützlichsten, wenn bestimmte Pakete Probleme beim Bau mit benutzerdefinierten Buildflags haben.

makeflags

ermöglicht die Nutzung benutzerdefinierter Makeflags während des Bauvorgangs mit build(), wie in makepkg.conf(5) angegeben. Dies ist in der negierten Form »!makeflags« am nützlichsten, wenn bestimmte Pakete Probleme beim Bau mit benutzerdefinierten Makeflags haben, wie -j2 (oder höher).

debug

fügt 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 enthält.

lto

aktiviert den Paketbau mittels Linkzeit-Optimierung. Fügt -flto zu CFLAGS und CXXFLAGS hinzu .

Außer den oben genannten Anweisungen benötigen 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 ausgeführt, so dass Sie hier alles verwenden können, was die Bash oder das System versteht. Stellen Sie sicher, dass eventuelle exotische Befehle durch die Abhängigkeiten im »makedepends«-Feld zur Verfügung gestellt werden.

Falls Sie in einer dieser Funktionen eigene Variablen definieren, ist es empfehlenswert, diese mit dem Bash-Schlüsselwort »local« auf den Bereich innerhalb der jeweiligen Funktion zu beschränken.

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 ausgeführt. Die Paketierungsstufe wird in einer Fakeroot-Umgebung ausgeführt, 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 ausführt..

prepare()-Funktion

Eine optionale prepare()-Funktion kann angegeben werden, in der die Quellen für den Bau vorbereitet werden, zum Beispiel durch Patchen. Diese Funktion wird nach dem Entpacken der Quellen und vor der build()-Funktion ausgeführt. Die prepare()-Funktion wird übersprungen, wenn das Entpacken der Quellen übersprungen wird.

build()-Funktion

Die optionale »build()«-Funktion wird zum Kompilieren und/oder Anpassen der Quelldateien verwendet, um diese für die Installation durch die »package()«-Funktion vorzubereiten.

check()-Funktion

Eine optionale check()-Funktion kann angegeben werden, welche die Testsuite eines Pakets ausführt. Diese Funktion wird zwischen den Funktionen build() und package() ausgeführt. Stellen Sie sicher, dass eventuelle exotische Befehle durch die Abhängigkeiten im »makedepends«-Feld zur Verfügung gestellt werden.

Alle der oben genannten Variablen wie $pkgname und $pkgver können in den Paketierungsfunktionen verwendet werden. Zusätzlich 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 ausgeführt.

pkgdir

gibt das Verzeichnis an, in dem Makepkg das installierte Paket zusammenstellt. Dieses Verzeichnis wird zum Wurzelverzeichnis Ihres gebauten Pakets. Diese Variable sollte ausschließlich 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.

Makepkg unterstützt den Bau mehrerer Pakete aus einem einzigen PKGBUILD. Dafür 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 für die Teilpakete verwenden in der Voreinstellung die im PKGBUILD angegebenen globalen Werte. Dennoch können Sie die folgenden innerhalb der Paketierungsfunktion jedes Teilpakets außer Kraft setzen: pkgdesc, arch, url, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options, install und changelog.

Beachten Sie, dass Makepkg die Abhängigkeiten der Teilpakete nicht berücksichtigt, wenn die Abhängigkeitsauflösung vor dem Bau des Pakets und mit --syncdeps erfolgt. Alle für den Bau des Pakets benötigten Pakete müssen in den globalen »depends«- und »makedepends«-Feldern angegeben werden.

Eine optionale globale Anweisung ist beim Bau eines geteilten Pakets verfügbar:

pkgbase

Dies ist der Name, der bei Bezügen 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. Für diese Variable sind alphanumerische Zeichen sowie die Zeichen »@«, ».«, »_«, »+« und »-« zulässig. Außerdem darf der Variablenname nicht mit Bindestrichen oder Punkten beginnen.

Pacman kann beim Installieren, Entfernen oder Aktualisieren eines Pakets ein paketspezifisches Skript speichern und ausführen. Dadurch kann sich ein Paket nach der Installation selbst konfigurieren und beim Entfernen den umgekehrten Vorgang ausführen.

Der exakte Zeitpunkt der Ausführung des Skripts ist von der jeweiligen Operation abhängig und sollte selbsterklärend sein. Beachten Sie, dass während einer Aktualisierungsoperation keine der Installations- oder Entfernungsfunktionen aufgerufen wird.

Den Skripten werden entweder eine oder zwei »vollständige Versionszeichenketten« übergeben, wobei eine vollständige Versionszeichenkette entweder pkgver-pkgrel oder epoch:pkgver-pkgrel lautet, falls »epoch« nicht Null ist.

pre_install

wird unmittelbar vor dem Entpacken der Dateien ausgeführt. Ein Argument wird übergeben: die vollständige Versionszeichenkette des neuen Pakets.

post_install

wird unmittelbar vor dem Entpacken der Dateien ausgeführt. Ein Argument wird übergeben: die vollständige Versionszeichenkette des neuen Pakets.

pre_upgrade

wird unmittelbar vor dem Entpacken der Dateien ausgeführt. Zwei Argumente werden in folgender Reihenfolge übergeben: die vollständige Versionszeichenkette des neuen Pakets und die vollständige Versionszeichenkette des alten Pakets.

post_upgrade

wird nach dem Entpacken der Dateien ausgeführt. Zwei Argumente werden in folgender Reihenfolge übergeben: die vollständige Versionszeichenkette des neuen Pakets und die vollständige Versionszeichenkette des alten Pakets.

pre_remove

wird unmittelbar vor dem Entfernen der Dateien ausgeführt. Ein Argument wird übergeben: die vollständige Versionszeichenkette des alten Pakets.

post_remove

wird unmittelbar nach dem Entfernen der Dateien ausgeführt. Ein Argument wird übergeben: die vollständige 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 für eine solche Installationsdatei finden Sie in /usr/share/pacman als proto.install. Sie referenziert alle verfügbaren definierten Funktionen.

Sie können den Bau eines Pakets aus einem Versionsverwaltungssystem (VCS) aktivieren, indem Sie die Quelle in der folgenden Form angeben:

source=('Verzeichnis::URL#Fragment?Abfrage')

Gegenwärtig unterstützt Makepkg die Versionsverwaltungssysteme Bazaar, Git, Subversion, Fossil und Mercurial. Für andere Versionsverwaltungssysteme müssen Sie das Klonen des Upstream-Repositoriums manuell in der prepare()-Funktion ausführen.

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 enthält, können Sie ihn hinzufügen, indem Sie vcs+ der URL voranstellen. Wenn Sie beispielsweise ein Git-Repositorium über HTTPS verwenden, würde 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, würde die Quellen-Zeile source=(URL#Revision=123) lauten. Die verfügbaren Typen sind vom verwendeten VCS abhängig:

bzr

revision (siehe 'bzr help revisionspec' für 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. Gegenwärtig wird dies nur von Git unterstützt.

Nachfolgend sehen Sie ein Beispiel-PKGBUILD für 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 <joe.user@example.com>
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
}

makepkg(8), pacman(8), makepkg.conf(5)

Auf der Pacman-Website finden Sie aktuelle Informationen zu Pacman und den zugehörigen Werkzeugen.

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 möglich in der Fehlerdatenbank von Archlinux im Bereich »Pacman«.

Derzeitige Betreuer:

• Allan McRae
• Andrew Gregory
• Eli Schwartz
• Morgan Adamiec

Bedeutende frühere Mitwirkende:

• Judd Vinet
• Aurelien Foret
• Aaron Griffin
• Dan McGee
• Xavier Chantry
• Nagy Gábor
• Dave Reisner

Informationen zu weiteren Mitwirkenden erhalten Sie, wenn Sie den Befehl git shortlog -s im Git-Repositorium pacman.git aufrufen.

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Mario Blättermann <mario.blaettermann@gmail.com> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.

6. Februar 2024 Pacman 6.0.2