Ubuntu Manpage: PKGBUILD - Beschreibungsdatei für den Bau von Paketen

BEZEICHNUNG

       PKGBUILD - Beschreibungsdatei für den Bau von Paketen

ÜBERSICHT

       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 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.

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 ü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)
Dieses Feld spezifiziert die für das Paket anzuwendenden Lizenzen. Falls mehrere Lizenzen gelten,
führen 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).

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.

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 .

PAKETIERUNGSFUNKTIONEN

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.. Diese
Funktion wird innerhalb von $srcdir aufgerufen.

verify()-Funktion
Es kann eine optionale Funktion verify() spezifiziert werden, um beliebige Quellauthentifizierungen
zu implementieren. Diese Funktion sollte einen von Null verschiedenen Exit-Code zurückliefern, wenn
die Authentifizierung fehlschlägt. Diese Funktion wird vor dem Extrahieren von Quellen ausgeführt.
Diese Funktion läuft innerhalb von $startdir.

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. Diese Funktion wird innerhalb von $srcdir aufgerufen.

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. Diese Funktion wird
innerhalb von $srcdir aufgerufen.

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. Diese Funktion wird innerhalb von $srcdir aufgerufen.

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.

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.

TEILEN VON PAKETEN

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.

SKRIPTE ZUM INSTALLIEREN/AKTUALISIEREN/ENTFERNEN

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.

QUELLEN AUS VERSIONSVERWALTUNGSSYSTEMEN VERWENDEN

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.

Einige VCS-Quellen wie Git unterstützen das Festhalten des Checkouts über eine Prüfsumme seines Inhalts
mittels deterministischer Exportfunktionalität wie »git archive«.

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.

BEISPIEL

       Nachfolgend sehen Sie ein Beispiel-PKGBUILD für das Paket patch. Weitere Beispiele finden Sie in den
       Bauskripten der Pakete Ihrer Distribution.

           # 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})
           sha256sums=('9124ba46db0abd873d0995c2ca880e81252676bb6c03e0a37dfc5f608a9b0ceb'
                       '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 zugehörigen Werkzeugen.

FEHLER

       Fehler? Sie machen wohl Witze, es gibt keine Fehler in dieser Software. Nun ja, sollte unsere Annahme
       doch falsch sein, berichten Sie diese (auf Englisch) in dem Fehlererfassungssystem unter
       https://gitlab.archlinux.org/pacman/pacman/-/issues zusammen mit den konkreten Informationen wie Ihre
       Befehlszeile, die Art des Fehlers und sogar der Paketdatenbank, falls das hilft.

AUTOREN

       Derzeitige Betreuer:

       •   Allan McRae

       •   Andrew Gregory

       •   Morgan Adamiec

       Bedeutende frühere Mitwirkende:

       •   Judd Vinet

       •   Aurelien Foret

       •   Aaron Griffin

       •   Dan McGee

       •   Xavier Chantry

       •   Nagy Gábor

       •   Dave Reisner

       •   Eli Schwartz

       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>
       und Helge Kreutzmann <debian@helgefjell.de> 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: debian-l10n-german@lists.debian.org.

Pacman 7.0.0                                     20. Januar 2025                                     PKGBUILD(5)