.\" -*- coding: UTF-8 -*-
'\" t
.\"     Title: pkgbuild
.\"    Author: [see the "Authors" section]
.\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
.\"      Date: 2024-02-06
.\"    Manual: Pacman Manual
.\"    Source: Pacman 6.0.2
.\"  Language: English
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH PKGBUILD 5 "6. Februar 2024" "Pacman 6\&.0\&.2" Pacman\-Handbuch
.ie  \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH BEZEICHNUNG
PKGBUILD \- Beschreibungsdatei für den Bau von Archlinux\-Paketen
.SH ÜBERSICHT
.sp
PKGBUILD
.SH BESCHREIBUNG
.sp
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\&.
.if  n \{\
.sp
.\}
.RS 4
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBHinweis\fP
.ps -1
.br
.sp
Einen beispielhaften PKGBUILD für Referenzzwecke finden Sie in
\fI/usr/share/pacman\fP 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\&.
.sp .5v
.RE
.SH "OPTIONEN UND ANWEISUNGEN"
.sp
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 \fBpkgname\fP, \fBpkgver\fP, \fBpkgrel\fP und
\fBarch\fP\&.
.sp
Wenn Sie benutzerdefinierte Variablen erstellen wollen, um diese im
Bauprozess zu verwenden, wird empfohlen, deren Namen einen \fI_\fP
(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\&.
.PP
\fBpkgname (Feld)\fP
.RS 4
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\&.
.RE
.PP
\fBpkgver\fP
.RS 4
gibt die vom herausgebenden Autor festgelegte Version des Pakets an
(beispielsweise \fI2\&.7\&.1\fP)\&. Die Variable darf keine Doppelpunkte,
Schrägstriche, Bindestriche oder Leerräume enthalten\&.
.sp
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)\&.
.RE
.PP
\fBpkgrel\fP
.RS 4
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 \fI1\fP 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)\&.
.RE
.PP
\fBepoch\fP
.RS 4
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 \fI0\fP 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
\fBpacman\fP(8) für weitere Informationen zu Versionsvergleichen\&.
.RE
.PP
\fBpkgdesc\fP
.RS 4
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\&.
.RE
.PP
\fBurl\fP
.RS 4
enthält eine URL, die mit der paketierten Software korrespondiert\&. Dies
ist typischerweise die Webseite des Projekts\&.
.RE
.PP
\fBlicense (Feld)\fP
.RS 4
legt die für das Paket relevant(en) Lizenz(en) fest\&. Häufig verwendete
Lizenzen finden Sie in \fI/usr/share/licenses/common\fP\&. Falls die Lizenz
Ihres Pakets dort aufgeführt ist, können Sie im Lizenzfeld direkt darauf
verweisen (zum Beispiel license=(\*(AqGPL\*(Aq))\&. Falls das Paket unter
die Bedingungen einer Lizenz fällt, die in \fI/usr/share/licenses/common\fP
nicht enthalten ist, sollten Sie diese direkt im Paket mitliefern und
license=(\*(Aqcustom\*(Aq) oder license=(\*(Aqcustom:LicenseName\*(Aq)
verwenden\&. Die Lizenz sollte beim Bau des Pakets in
\fI$pkgdir/usr/share/licenses/$pkgname/\fP gespeichert werden\&. Wenn mehrere
Lizenzen anwendbar sind, listen Sie sie alle auf: license=(\*(AqGPL\*(Aq
\*(AqFDL\*(Aq)\&.
.RE
.PP
\fBinstall\fP
.RS 4
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)\&.
.RE
.PP
\fBchangelog\fP
.RS 4
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)\&.
.RE
.PP
\fBsource (Feld)\fP
.RS 4
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\&.
.sp
Zusätzliche architekturspezifische Quellen können Sie hinzufügen, indem Sie
ihnen einen Unterstrich und den Architekturnamen anhängen, zum Beispiel
\fIsource_x86_64=()\fP\&. Ein korrespondierendes Integritätsfeld mit Prüfsummen
muss vorhanden sein, zum Beispiel \fIcksums_x86_64=()\fP\&.
.sp
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=(\*(AqDateiname::URL\*(Aq)\&.
.sp
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«\&.
.sp
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\&.
.RE
.PP
\fBvalidpgpkeys (Feld)\fP
.RS 4
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\&.
.sp
Es werden nur vollständige Fingerabdrücke akzeptiert\&. Diese müssen in
Großschreibung vorliegen und dürfen keine Leerräume enthalten\&.
.RE
.PP
\fBnoextract (Feld)\fP
.RS 4
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\&.
.RE
.PP
\fBcksums (Feld)\fP
.RS 4
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 \fISKIP\fP 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.
.RE
.PP
\fBmd5sums, sha1sums, sha224sums, sha256sums, sha384sums, sha512sums, b2sums (Felder)\fP
.RS 4
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 \fBmakepkg.conf\fP(5) konfiguriert
ist\&.
.RE
.PP
\fBgroups (Feld)\fP
.RS 4
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
\fIkde\fP installieren\&.
.RE
.PP
\fBarch (Feld)\fP
.RS 4
legt fest, auf welchen Architekturen das angegebene Paket verfügbar ist (zum
Beispiel arch=(\*(Aqi686\*(Aq \*(Aqx86_64\*(Aq))\&. Pakete, die keine
architekturspezifischen Dateien enthalten, sollten arch=(\*(Aqany\*(Aq)
verwenden\&. Sie können für die Angabe alphanumerische Zeichen und den
Unterstrich »_« verwenden\&.
.RE
.PP
\fBbackup (Feld)\fP
.RS 4
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
\fI/etc\fP ablegen\&. Siehe »Umgang mit Konfigurationsdateien« in \fBpacman\fP(8)
für weitere Informationen\&.
.RE
.PP
\fBdepends (Feld)\fP
.RS 4
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
\fIName<>version\fP enthalten, wobei <> einer von fünf
Vergleichsoperatoren ist: >= (größer oder gleich), <= (kleiner oder
gleich), = (gleich), > (größer als) oder < (kleiner als)\&.
.sp
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\&.
.sp
Zusätzliche architekturspezifische Abhängigkeiten können Sie hinzufügen,
indem Sie ihnen einen Unterstrich und den Architekturnamen anhängen, zum
Beispiel \fIdepends_x86_64=()\fP\&.
.RE
.PP
\fBmakedepends (Feld)\fP
.RS 4
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«\&.
.sp
Weitere archtekturabhängige Bau\-Abhängigkeiten können Sie angeben, indem Sie
einen Unterstrich und den Namen der Architektur anhängen, zum Beispiel
\fImakedepends_x86_64=()\fP\&.
.RE
.PP
\fBcheckdepends (Feld)\fP
.RS 4
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\&.
.sp
Zusätzliche architekturspezifische »checkdepends«\-Abhängigkeiten können Sie
hinzufügen, indem Sie ihnen einen Unterstrich und den Architekturnamen
anhängen, zum Beispiel \fIcheckdepends_x86_64=()\fP\&.
.RE
.PP
\fBoptdepends (Feld)\fP
.RS 4
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:
.sp
.if  n \{\
.RS 4
.\}
.nf
optdepends=(\*(Aqpython: for library bindings\*(Aq)
.fi
.if  n \{\
.RE
.\}
.sp
Zusätzliche architekturspezifische »optdepends«\-Abhängigkeiten können Sie
hinzufügen, indem Sie ihnen einen Unterstrich und den Architekturnamen
anhängen, zum Beispiel \fIoptdepends_x86_64=()\fP\&.
.RE
.PP
\fBconflicts (Feld)\fP
.RS 4
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\&.
.sp
Zusätzliche architekturspezifische Konflikte können Sie hinzufügen, indem
Sie ihnen einen Unterstrich und den Architekturnamen anhängen, zum Beispiel
\fIconflicts_x86_64=()\fP\&.
.RE
.PP
\fBprovides (Feld)\fP
.RS 4
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 \fIcron\fP bereitstellen, wodurch Pakete von \fIcron\fP
abhängen können und nicht von \fIdcron ODER fcron\fP\&.
.sp
Die Versionierung der virtuellen Bereitstellung ist im Format
\fIName=Version\fP möglich\&. Beispielsweise kann »dcron« außerdem
\fIcron=2\&.0\fP bereitstellen, um die Abhängigkeit anderer Pakete zu
\fIcron>=2\&.0\fP zu erfüllen\&. Bereitstellungen, welche die Operatoren
> und < enthalten, sind unzulässig, weil nur spezifische Versionen
eines Pakets bereitgestellt werden\&.
.sp
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\&.
.sp
Zusätzliche architekturspezifische Bereitstellungen können Sie hinzufügen,
indem Sie ihnen einen Unterstrich und den Architekturnamen anhängen, zum
Beispiel \fIprovides_x86_64=()\fP\&.
.RE
.PP
\fBreplaces (Feld)\fP
.RS 4
Ein Feld aus Paketen, welche dieses Paket ersetzt\&. Dies kann dazu dienen,
umbenannte oder zusammengefasste Pakete zu verarbeiten\&. Wenn
beispielsweise das Paket \fIj2re\fP in \fIjre\fP 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\&.
.sp
Eine Systemaktualisierung ist derzeit der einzige Vorgang, bei dem Pacman
dieses Feld berücksichtigt\&. Eine normale Synchronisation oder
Aktualisierung verwendet dessen Wert nicht\&.
.sp
Zusätzliche architekturspezifische Ersetzungen können Sie hinzufügen, indem
Sie ihnen einen Unterstrich und den Architekturnamen anhängen, zum Beispiel
\fIreplaces_x86_64=()\fP\&.
.RE
.PP
\fBoptions (Feld)\fP
.RS 4
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 \fBmakepkg.conf\fP(5)
übernommen\&. \fBHINWEIS:\fP Die Option \fIforce\fP wurde entfernt und deren
Wirkung durch die Variable \fIepoch\fP auf der obersten Ebene ersetzt\&.
.PP
\fBstrip\fP
.RS 4
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\&.
.RE
.PP
\fBdocs\fP
.RS 4
speichert die Dokumentationsverzeichnisse\&. Wenn Sie die
Dokumentationsverzeichnisse löschen wollen, geben Sie »!docs« im Feld an\&.
.RE
.PP
\fBlibtool\fP
.RS 4
Belässt Libtool\-Dateien (\&.la) in Paketen\&. Geben Sie !libtool an, um
diese zu entfernen\&.
.RE
.PP
\fBstaticlibs\fP
.RS 4
Belässt statische Bibliotheksdateien (\&.a) in Paketen\& Geben Sie
!staticlibs an, um diese zu entfernen (sofern es ein dynamisch gelinktes
Gegenstück gibt)\&.
.RE
.PP
\fBemptydirs\fP
.RS 4
belässt leere Verzeichnisse in Paketen\&.
.RE
.PP
\fBzipman\fP
.RS 4
komprimiert Handbuchseiten (man und info) mit gzip\&.
.RE
.PP
\fBccache\fP
.RS 4
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\&.
.RE
.PP
\fBdistcc\fP
.RS 4
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\&.
.RE
.PP
\fBbuildflags\fP
.RS 4
ermöglicht die Nutzung benutzerdefinierter Buildflags (CPPFLAGS, CFLAGS,
CXXFLAGS, LDFLAGS) während des Bauvorgangs mit build(), wie in
\fBmakepkg.conf\fP(5) angegeben\&. Dies ist in der negierten Form »!buildflags«
am nützlichsten, wenn bestimmte Pakete Probleme beim Bau mit
benutzerdefinierten Buildflags haben\&.
.RE
.PP
\fBmakeflags\fP
.RS 4
ermöglicht die Nutzung benutzerdefinierter Makeflags während des Bauvorgangs
mit build(), wie in \fBmakepkg.conf\fP(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)\&.
.RE
.PP
\fBdebug\fP
.RS 4
fügt die benutzerdefinierten Debug\-Flags (DEBUG_CFLAGS, DEBUG_CXXFLAGS) zu
den korrespondierenden Buildflags hinzu, wie in \fBmakepkg.conf\fP(5)
angegeben\&. Wird dies in Verbindung mit der Option »strip« verwendet, wird
ein separates Paket erstellt, das die Debug\-Symbole enthält\&.
.RE
.PP
\fBlto\fP
.RS 4
aktiviert den Paketbau mittels Linkzeit\-Optimierung\&. Fügt \fI\-flto\fP zu
CFLAGS und CXXFLAGS hinzu \&.
.RE
.RE
.SH PAKETIERUNGSFUNKTIONEN
.sp
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\&.
.sp
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\&.
.sp
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\&.
.PP
\fBpackage()\-Funktion\fP
.RS 4
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.\&.
.RE
.PP
\fBprepare()\-Funktion\fP
.RS 4
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\&.
.RE
.PP
\fBbuild()\-Funktion\fP
.RS 4
Die optionale »build()«\-Funktion wird zum Kompilieren und/oder Anpassen der
Quelldateien verwendet, um diese für die Installation durch die
»package()«\-Funktion vorzubereiten\&.
.RE
.PP
\fBcheck()\-Funktion\fP
.RS 4
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\&.
.RE
.sp
Alle der oben genannten Variablen wie $pkgname und $pkgver können in den
Paketierungsfunktionen verwendet werden\&. Zusätzlich definiert Makepkg die
folgenden Variablen:
.PP
\fBsrcdir\fP
.RS 4
gibt das Verzeichnis an, in das Makepkg alle Quelldateien entpackt
bzw\&. kopiert\&.
.sp
Alle der oben definierten Paketierungsfunktionen werden im Verzeichnis
$srcdir ausgeführt\&.
.RE
.PP
\fBpkgdir\fP
.RS 4
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\&.
.RE
.PP
\fBstartdir\fP
.RS 4
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\&.
.RE
.SH "TEILEN VON PAKETEN"
.sp
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\&.
.sp
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\&.
.sp
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\&.
.sp
Eine optionale globale Anweisung ist beim Bau eines geteilten Pakets
verfügbar:
.PP
\fBpkgbase\fP
.RS 4
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\&.
.RE
.SH "SKRIPTE ZUM INSTALLIEREN/AKTUALISIEREN/ENTFERNEN"
.sp
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\&.
.sp
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\&.
.sp
Den Skripten werden entweder eine oder zwei »vollständige
Versionszeichenketten« übergeben, wobei eine vollständige
Versionszeichenkette entweder \fIpkgver\-pkgrel\fP oder \fIepoch:pkgver\-pkgrel\fP
lautet, falls »epoch« nicht Null ist\&.
.PP
\fBpre_install\fP
.RS 4
wird unmittelbar vor dem Entpacken der Dateien ausgeführt\&. Ein Argument
wird übergeben: die vollständige Versionszeichenkette des neuen Pakets\&.
.RE
.PP
\fBpost_install\fP
.RS 4
wird unmittelbar vor dem Entpacken der Dateien ausgeführt\&. Ein Argument
wird übergeben: die vollständige Versionszeichenkette des neuen Pakets\&.
.RE
.PP
\fBpre_upgrade\fP
.RS 4
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\&.
.RE
.PP
\fBpost_upgrade\fP
.RS 4
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\&.
.RE
.PP
\fBpre_remove\fP
.RS 4
wird unmittelbar vor dem Entfernen der Dateien ausgeführt\&. Ein Argument
wird übergeben: die vollständige Versionszeichenkette des alten Pakets\&.
.RE
.PP
\fBpost_remove\fP
.RS 4
wird unmittelbar nach dem Entfernen der Dateien ausgeführt\&. Ein Argument
wird übergeben: die vollständige Versionszeichenkette des alten Pakets\&.
.RE
.sp
Um dieses Funktionsmerkmal zu nutzen, legen Sie eine Datei namens
\fIPaketname\&.install\fP an und speichern Sie sie im gleichen Verzeichnis wie
das PKGBUILD\-Skript\&. Dann verwenden Sie folgende Installationsanweisung:
.sp
.if  n \{\
.RS 4
.\}
.nf
install=Paketname\&.install
.fi
.if  n \{\
.RE
.\}
.sp
Das Installationsskript muss im »source«\-Feld nicht angegeben werden\&. Eine
Vorlage für eine solche Installationsdatei finden Sie in
\fI/usr/share/pacman\fP als \fIproto\&.install\fP\&. Sie referenziert alle
verfügbaren definierten Funktionen\&.
.SH "QUELLEN AUS VERSIONSVERWALTUNGSSYSTEMEN VERWENDEN"
.sp
Sie können den Bau eines Pakets aus einem Versionsverwaltungssystem (VCS)
aktivieren, indem Sie die Quelle in der folgenden Form angeben:
.sp
.if  n \{\
.RS 4
.\}
.nf
source=(\*(AqVerzeichnis::URL#Fragment?Abfrage\*(Aq)
.fi
.if  n \{\
.RE
.\}
.sp
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\&.
.sp
Die Quellen\-URL besteht aus vier Komponenten:
.PP
\fBVerzeichnis\fP
.RS 4
(optional) Gibt den Namen eines alternativen Verzeichnisses an, in das
Makepkg die VCS\-Quellen herunterladen soll\&.
.RE
.PP
\fBurl\fP
.RS 4
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://…\&.
.RE
.PP
\fBFragment\fP
.RS 4
(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:
.PP
\fBbzr\fP
.RS 4
revision (siehe \*(Aqbzr help revisionspec\*(Aq für Details)
.RE
.PP
\fBfossil\fP
.RS 4
branch, commit, tag
.RE
.PP
\fBgit\fP
.RS 4
branch, commit, tag
.RE
.PP
\fBhg\fP
.RS 4
branch, revision, tag
.RE
.PP
\fBsvn\fP
.RS 4
revision
.RE
.RE
.PP
\fBquery\fP
.RS 4
(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\&.
.RE
.SH BEISPIEL
.sp
Nachfolgend sehen Sie ein Beispiel\-PKGBUILD für das Paket
\fIpatch\fP\&. Weitere Beispiele finden Sie in den Bauskripten der Pakete Ihrer
Distribution\&. Nutzer von Archlinux sollten sich das Arch Build System
(ABS) anschauen\&.
.sp
.if  n \{\
.RS 4
.\}
.nf
# 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=(\*(Aqi686\*(Aq \*(Aqx86_64\*(Aq)
url="https://www\&.gnu\&.org/software/patch/patch\&.html"
license=(\*(AqGPL\*(Aq)
groups=(\*(Aqbase\-devel\*(Aq)
depends=(\*(Aqglibc\*(Aq)
makedepends=(\*(Aqed\*(Aq)
optdepends=(\*(Aqed: for "patch \-e" functionality\*(Aq)
source=("ftp://ftp\&.gnu\&.org/gnu/$pkgname/$pkgname\-$pkgver\&.tar\&.xz"{,\&.sig})
md5sums=(\*(Aqe9ae5393426d3ad783a300a338c09b72\*(Aq
         \*(AqSKIP\*(Aq)

build() {
        cd "$srcdir/$pkgname\-$pkgver"
        \&./configure \-\-prefix=/usr
        make
}

package() {
        cd "$srcdir/$pkgname\-$pkgver"
        make DESTDIR="$pkgdir/" install
}
.fi
.if  n \{\
.RE
.\}
.SH "SIEHE AUCH"
.sp
\fBmakepkg\fP(8), \fBpacman\fP(8), \fBmakepkg.conf\fP(5)
.sp
Auf der
.UR https://archlinux\&.org/pacman/
Pacman\-Website
.UE
finden
Sie aktuelle Informationen zu Pacman und den zugehörigen Werkzeugen\&.
.SH FEHLER
.sp
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
.UR https://bugs.archlinux.org/
Fehlerdatenbank von Archlinux
.UE
im
Bereich »Pacman«\&.
.SH AUTOREN
.sp
Derzeitige Betreuer:
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT allan@archlinux\&.org
Allan McRae
.ME
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT andrew\&.gregory\&.8@gmail\&.com
Andrew Gregory
.ME
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT eschwartz@archlinux\&.org
Eli Schwartz
.ME
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT morganamilo@archlinux\&.org
Morgan Adamiec
.ME
.RE
.sp
Bedeutende frühere Mitwirkende:
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT jvinet@zeroflux\&.org
Judd Vinet
.ME
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT aurelien@archlinux\&.org
Aurelien Foret
.ME
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT aaron@archlinux\&.org
Aaron Griffin
.ME
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT dan@archlinux\&.org
Dan McGee
.ME
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT shiningxc@gmail\&.com
Xavier Chantry
.ME
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT ngaba@bibl\&.u\-szeged\&.hu
Nagy Gábor
.ME
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
.MT dreisner@archlinux\&.org
Dave Reisner
.ME
.RE
.sp
Informationen zu weiteren Mitwirkenden erhalten Sie, wenn Sie den Befehl
\fBgit shortlog \-s\fP im Git\-Repositorium pacman\&.git aufrufen\&.
.PP
.SH ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von
Mario Blättermann <mario.blaettermann@gmail.com>
erstellt.
.PP
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License Version 3
.UE
oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
.PP
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden,
schicken Sie bitte eine E-Mail an die
.MT debian-l10n-german@lists.debian.org
Mailingliste der Übersetzer
.ME .