Arch Build System: Unterschied zwischen den Versionen

Aus wiki.archlinux.de
← Zum vorherigen Versionsunterschied
Wtfoo (Diskussion | Beiträge)
18 Bearbeitungen
Keine Bearbeitungszusammenfassung
 
(93 dazwischenliegende Versionen von 22 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
[[Kategorie:Paketverwaltung]]
{{veraltet}}
==== Einführung ====
{{achtung|Mit Wirkung vom 16.05.2017 existiert das Paket extra/abs nicht mehr. Die neue offizielle Alternative heißt asp. Bitte beachtet in diesem Zusammenhang die [https://github.com/falconindy/asp/blob/master/man/asp.1.txt Manpage].}}
 
Das Arch Build System (ABS) wird genutzt um:
Das Arch Build System (ABS) wird genutzt um:


* Neue Pakete für Software zu erstellen, für die noch keine Pakete vorhanden sind
* Neue Pakete für Software zu erstellen
* Vorhande Pakete an die eigenen Bedürfnisse anzupassen
* Vorhande Pakete an die eigenen Bedürfnisse anzupassen
* Das komplette System mit eigenen Compiler-flags neuzubauen, "a la gentoo" (Und so Kernel Module mit eigenem Kernel nutzbar machen!)
ABS ist nicht notwendig um Arch Linux zu nutzen, aber es ist nützlich.


Dieses How-To versucht dir eine Übersicht über ABS und Arch Pakete zu geben, es ist keine komplette Referenz! Wenn du mehr willst, solltest du einen Blick in die man-pages werfen.
Das Arch Build System besteht aus einem Werkzeug zum Herunterladen der PKGBUILDS (offiziell asp, alternativ z.B. [[AUR Hilfsprogramme|pbget]]), [[Abs#Erstellung_von_Paketen|makepkg]] und [[pacman]].
Dieser Artikel versucht nun eine Übersicht über das Erstellen von Paketen unter Archlinux zu geben. Detailreichere Informationen finden sich in den jeweiligen [[Manpages]].


==== Vorbereitung ====
== Vorbereitung ==


Um ABS zu nutzen, musst du zuerst die Programme "cvsup" und "wget" installieren:
Man benötigt ein Tool, um das oder die PKGBUILDS, an denen man interessiert ist, herunter zu laden. Dazu kann man das Paket {{paket|asp}} installieren:


<pre>
pacman -S asp
pacman -Sy cvsup wget</pre>


Oder, wenn du die Pakete z.B. in den Ordner 'foo' gedownloaded hast:
Dieses Paket wendet sich allerdings weniger an den gelegentlichen Paketersteller als an den Arch Linux Entwickler oder TU.  Das erkennt man daran, dass die Pakete in einer Verzeichnisstruktur heruntergeladen werden, die der entspricht, die auf den offizellen Entwicklungsserver vorliegt. Ein Beispiel
<pre>
asp checkout emacs
cd foo
erzeugt ein Verzeichnis /var/tmp/emacs und darunter
pacman -A cvsup-*.pkg.tar.gz wget-*.pkg.tar.gz</pre>
$ ls -lR /var/tmp/emacs
  /var/tmp/emacs:
nsgesamt 8
drwxr-xr-x 4 haawda users 4096  3. Sep 01:03 repos
drwxr-xr-x 2 haawda users 4096  3. Sep 01:03 trunk
/var/tmp/emacs/repos:
insgesamt 8
drwxr-xr-x 2 haawda users 4096  3. Sep 01:03 extra-i686
  drwxr-xr-x 2 haawda users 4096  3. Sep 01:03 extra-x86_64
/var/tmp/emacs/repos/extra-i686:
insgesamt 4
-rw-r--r-- 1 haawda users 1546  3. Sep 01:03 PKGBUILD
/var/tmp/emacs/repos/extra-x86_64:
insgesamt 4
-rw-r--r-- 1 haawda users 1546  3. Sep 01:03 PKGBUILD
/var/tmp/emacs/trunk:
insgesamt 4
-rw-r--r-- 1 haawda users 1546  3. Sep 01:03 PKGBUILD


==== Was ist ein Paket ?====
Das ist eine Struktur, mit der der gelegentliche Paketersteller vermutlich nicht arbeiten will. Hier bietet sich an, auf ein Tool wie pbget zurückzugreifen. pbget ist dem Ursprung nach eher ein AUR-Helper, kann aber auch offizielle PKGBUILDS herunterladen.
pbget emacs
z.B. erzeugt im aktuellen Verzeichnis ein Unterverzeichnis mit den Dateien, die man zur Erzeugung des offiziellen emacs-Paketes braucht. Das ist erheblich einfacher zu durchschauen.


Ein Paket ist eine Datei, die meistens ''foo''.pkg.tar.gz genannt ist.
Alle sonstigen Pakete, die zur Erstellung von Paketen notwendig sind, befinden sich in der Gruppe base-devel:


In fact, it is no more than a gzipped tar archive which contains:
pacman -S base-devel


* The files to install
== Das Paket ==


*.PKGINFO : contains all the metadata needed by pacman to deal with packages, dependencies, etc.
Ein Paket ist eine Datei, die der Namenskonvention ''foo''.pkg.tar.zst entspricht.


*.FILELIST : lists all the files of the archive. It's used in order to uninstall the software or to check for file conflicts.
Die Paketendung deutet es schon an: Es handelt sich um ein mit zstd komprimiertes tar-Archiv, das neben den eigentlichen Daten, die durch das Paket verwaltet werden sollen, noch folgendes enthält:


*.INSTALL : a file used to execute commands after the install/upgrade/remove stage. (This file is only present if specified in the PKGBUILD)
* Die zu installierenden Dateien


==== What is a PKGBUILD and what does it contain?====
*.PKGINFO : enthält alle Metadaten, die pacman für den Umgang mit Paketen, Abhängigkeiten etc. benötigt.


As explained before, the PKGBUILD file contains metadata about a package. It is a simple plain text file. Here is an example:
*.BUILDINFO : enthält weitere Metadaten über die Parameter, die beim Bau des Paketes aktiv waren, sowie eine Lister der zum Zeitpunkt des Bauens installierten Pakete.


<pre>
*.INSTALL : enthält Befehle, die nach dem Installieren/Aktualisieren/Deinstallieren ausgeführt werden. (Nur vorhanden, wenn es in PKGBUILD definiert wurde)
# $Id: PKGBUILD,v 1.12 2003/11/06 08:26:13 dorphell Exp $
# Maintainer: judd <jvinet@zeroflux.org>
# Contributor: Judd Vinet <jvinet@zeroflux.org>
pkgname=foo
pkgver=0.99 # note: if the pkgver had been '0.99-10' then use an underscore. like '0.99_10'
pkgrel=1
pkgdesc="short description of foo"
arch=(i686 x86_64)
url="http://www.foo.org"
groups=
provides=
depends=('qt' 'python')
makedepends=('guile')
conflicts=('yafoo')
replaces=('mffoo')
backup=('etc/foo/foo.conf')
install=('foo.install')
source=(http://www.foo.org/download/$pkgname-$pkgver.tar.gz)
md5sums=('2c0cca3ef6330a187c6ef4fe41ecaa4d35175bee593a7cc7d6205584a94d8625')


build() {
== Das PKGBUILD ==
  cd $startdir/src/$pkgname-$pkgver
  ./configure --prefix=/usr
  make || return 1
  make prefix=$startdir/pkg/usr install
}
</pre>


So let's explain each field :
Ein PKGBUILD enthält die Bauanweisungen und Metadaten über ein Paket, das von [[pacman]] installierbar sein soll. Es stellt die Grundlage für Pakete in Archlinux dar. Ein PKGBUILD ist eine einfache Textdatei, die Bash-Code (die PKGBUILDs einfach aus der bash heraus aufzurufen schlägt aber fehl. Sie werden von makepkg eingebunden.) enthält und beispielsweise so aussehen kann:


* '''# text''' : comments
# $Id: PKGBUILD,v 1.12 2003/11/06 08:26:13 dorphell Exp $
* '''# $Id: PKGBUILD,v ...''' : the cvs-tag for this pkg (from the archlinux-cvs system created)
# Maintainer: judd <jvinet@zeroflux.org>
* '''# Maintainer''' : the maintainer responsible for this pkg in the official Repositories
# Contributor: Judd Vinet <jvinet@zeroflux.org>
* '''# Contributor''' : the person who wrote the first PKGBUILD for this package
pkgname=foo
* '''pkgname''' : the name of the package
  pkgver=0.99 # note: if the pkgver had been '0.99-10' then use an underscore. like '0.99_10'
* '''pkgver''' : the version of the package
  pkgrel=1
* '''pkgrel''' : the release number of the Arch package. It is different from the version of the package and is changed when the PKGBUILD is modified. This can happen for many reasons, for example if you enable compile-time support for something.
  pkgdesc="short description of foo"
* '''pkgdesc''' : a brief description of the package. This is what you see when you browse the [http://archlinux.org/packages.php package database]
arch=(i686 x86_64)
* '''arch''' : shows on what architectures it is known to build and work - see [[Arch64_FAQ]] for porting details
  url="http://www.foo.org"
* '''url''' : the homepage of the software (which appears when you click on a package on the package database)
license=('GPL')
* '''groups''' : this is used to group packages: when you try to install kde for example, it installs all packages which belongs to the kde group
groups=
* '''provides''' : this is used if the package provides another package, for example, kernel-scsi provides kernel
provides=
* '''depends''' : this lists the run-time dependencies of the package (what it needs to work)
depends=('qt' 'python')
* '''makedepends''' : dependencies needed to build the package but which are not needed once the package is built
makedepends=('guile')
* '''conflicts''' : these packages cannot be installed at the same time. Here, <i>foo</i> conflicts with <i>yafoo (yet another foo)</i>. They cannot be installed at the same time.
conflicts=('yafoo')
* '''replaces''' : the new package replaces the old one. Here, <i>mffoo (my first foo)</i> is no more supported and being replaced with <i>foo</i>
replaces=('mffoo')
* '''backup''' : which files to backup (as file.pacsave) when the package is removed
backup=('etc/foo/foo.conf')
* '''install''' : specifies a special install script that is to be included in the package (it has to be in the same directory as PKGBUILD)
install='foo.install'
* '''source''' : this specifies from where to download the package's source code.  It can be a local package as well as a "http" of "ftp" one.  It is named using <i>pkgname</i> and <i>pkgver</i> in order to avoid changing the source each time the version changes.
source=(http://www.foo.org/download/$pkgname-$pkgver.tar.gz)
* '''md5sums''' : md5sums of the source to check their integrity
md5sums=('2c0cca3ef6330a187c6ef4fe41eca')
  build() {
  cd $srcdir/$pkgname-$pkgver
  ./configure --prefix=/usr
  make
  }
  package() {
  cd $srcdir/$pkgname-$pkgver
  make DESTDIR=$pkgdir install
}


So now, let's explain the function :
Erklärung:


* build : all the actions needed to build the package (it will be explained with more attention later in this document)
* '''# text''' : Kommentare
* '''# $Id: PKGBUILD,v ...''' : Das SVN-Tag für dieses Paket (automatisch vom Archlinux-SVN System erstellt). Dies sollte bei Paketen, die für das [[AUR]] gedacht sind, stets weggelassen werden.
* '''# Maintainer''' :  Der Betreuer für dieses Paket
* '''# Contributor''' : Jemand, der zu dem PKGBUILD darüber hinaus etwas beigetragen hat. Das kann zum Beispiel ein vorheriger Betreuer des Pakets sein.
* '''pkgbase''' : Optional, bei Nichtangabe wird automatisch der erste Wert im Array $pkgname verwendet. Kommt nur bei Split packages zum Tragen.
* '''pkgname''' :  Der Paketname, kann alternativ auch ein Array sein (Split Packages)
* '''pkgver''' : Die Paketversion
* '''pkgrel''' : Die Releasenummer des Arch Paketes. Wird geändert, wenn das PKGBUILD verändert wurde oder (bei Paketen aus den Repos) das Paket neu gebaut werden musste.
* '''pkgdesc''' : Eine Kurzbeschreibung des Paketes, zu sehen in der [http://www.archlinux.de/?page=Packages Paket Datenbank]
* '''arch''' : Die Architekturen, auf denen das Paket kompiliert und getestet wurde, oder 'any' bei plattformunabhängigen Paketen.
* '''url''' : Die Homepage des Programmes
* '''license''' : Die Lizenz, unter der das Programm steht
* '''groups''' :  Wird genutzt um Pakete zu Gruppen zusammen zu fassen. Wenn du z.B. KDE installieren willst, werden alle Pakete installiert, die zur Gruppe 'kde' gehören [https://www.archlinux.org/groups Liste der Gruppen] {{sprache|en}}
* '''provides''' : Wird genutzt, wenn das Paket ein anderes Paket bereitstellt.
* '''depends''' : Liste der Abhängigkeiten um das Programm auszuführen.
* '''makedepends''' : Liste der Abhängigkeiten um das Programm zu kompilieren. Pakete, die schon unter depends aufgeführt wurden, sind hier nicht noch einmal aufzuführen.
* '''conflicts''' : Pakete, die nicht zusammen mit diesem Programm installiert sein können. In unserem Fall steht  ''foo'' in Konflikt zu ''yafoo''.
* '''replaces''' : Das neue Paket ersetzt das alte. In unserem Fall wird ''mffoo'' nicht mehr unterstützt und wird durch ''foo'' ersetzt.
* '''backup''' : Dateien, die gesichert werden (als .pacsave), wenn das Programm deinstalliert wird.
* '''install''' : Spezifiziert ein Installationsskript, das im Paket enthalten ist. (Muss sich mit PKGBUILD im selben Verzeichnis befinden)
* '''source''' : Die Bezugsquelle(n) des Quelltextes. Kann sowohl ein lokales Paket, als auch ein remote "http" oder "ftp" Paket sein. Der Dateiname wird aus ''pkgname'' und ''pkgver'' erstellt, damit der Pfad nicht bei jeder neuen Version angepasst werden muss.
* '''md5sums''' : MD5 Summen der Quelltexte um beschädigte Dateien auszuschließen.
* '''build()''' : Alle Schritte, die nötig sind um den Quelltext zu übersetzen (optional). Die Schritte müssen mit normalen Benutzerrechte ausgeführt werden können.
* '''package()''': Alle Schritte, die nötig sind, um die nötigen Dateien ins eigentliche Paket zu übertragen.


Well, you see that the PKGBUILD file contains all the information that might be needed by the package manager. It is the heart of pacman and abs.
=== Die Build-Funktion und die Package-Funktion ===


There are also install files. This PKGBUILD specifies 'foo.install' as the package's install file. Here is an example install file:
Neben der Build- und der Package-Funktion kann es auch noch eine Prepare- und eine Pkgver-Funktion geben. Die prepare-Funktion dient dazu, Anpassungen am eigentlichen Quelltext vorzunehmen, und sollte nur in Ausnahmefällen verwendet werden (ein Beispiel siehe unten). Die pkgver-Funktion dient zur automatischen Generierung einer Paketversion und kommt hauptsächlich zum Tragen, wenn die Quellcodes über ein VCS bezogen werden. Reihenfolge der Ausführung:


<pre>
prepare(){}
post_install() {
pkgver(){}
/bin/true
build(){}
}
package(){}


post_upgrade() {
In der build-Funktion werden die Anweisungen ausgeführt, die nötig sind, um das Paket zu kompilieren. Sie kann entfallen (Binary-Blobs, Java-Jar-Files, Skripte).
/bin/true
}


pre_remove() {
In der package-Funktion werden die zu installierenden Dateien und Verzeichnisse so abgelegt, dass makepkg daraus einen Tarball - das Paket - erstellen kann, der dann von [[pacman]] installiert werden kann. In einem ersten Schritt geschieht die durch Anlegen eine Verzeichnisbaums namens 'pkg' (hirauf zeigt die Bash-Variable pkgdir). Es muss mindestens eine, kann aber auch mehrere Package-Funktionen geben. Bei mehreren package-Funktionen spricht man von [https://www.archlinux.org/pacman/PKGBUILD.5.html#_package_splitting Package Splitting].
/bin/true
----
}
Viele Pakete (nämlich die, die auf die Verwendung der GNU-Autotools hin ausgelegt sind) können über den ''Dreisatz'' erstellt werden:


op=$1
./configure --prefix=/usr
shift
make
make install


$op "$@"
''./configure'' überprüft zunächst, ob alle Voraussetzungen für das zu kompilierende Programm erfüllt sind. Über dieses Script lässt sich auch konfigurieren, wie und mit welchen Funktionen ein Programm kompiliert wird. ''./configure --help'' zeigt meistens eine Übersicht über die Optionen, die verfügbar sind. ''make'' kompiliert schließlich das Paket und '' make install'' installiert die Dateien.
</pre>


Here are the function explainations :
Du solltest immer die ''INSTALL'' oder die ''README'' Datei des jeweiligen Pakets lesen, um zu erfahren, wie es erstellt und installiert werden sollte, denn nicht alle Pakete nutzen diesen ''Dreisatz''! Bei neueren Build-Systemen (cmake, meson/ninja) ist es prinzipiell nicht anders, aber die Befehle  des ''Dreisatz'' lauten anders.
----


* post_install : this script is run right after files are installed, it takes one argument :
Eine 'Standard', autotools-basierte build-Funktion sieht so aus:
** the package version
* post_upgrade : this script is run after all files have been upgraded, <em>it takes two arguments</em> :
** the new package version
** the old package version
* pre_remove : this script is run right before files are removed (stop a daemon for example) and takes one argument :  
** the package version


The three lines at the bottom are needed in every install file so that they run properly.
build() {
 
   cd $pkgname-$pkgver
==== The build function====
 
If you're not familiar with building packages, you should know that most packages (but not all) can be built this way :
* uncompress the source file :
 
  <pre>
  tar -xzf foo-0.99.tar.gz
  tar -xjf foo-0.99.tar.bz2</pre>
 
* enter the directory
 
  <pre>cd foo-0.99</pre>
 
* configure the package : generally, there is a little script called <code>configure</code> in the source directory which is used to configure the package (add or remove support for things, choose the install destination, ...) and check that your computer has all the software needed by the package. it can be run by :
 
  <pre>./configure [[option]]</pre>
 
You should first try the help to better understand how it works :
 
  <pre>./configure --help</pre>
 
* compile the sources :
 
  <pre>make</pre>
 
* install
 
  <pre>make install</pre>
 
However, you should always read the <code>INSTALL</code> file to know how the package should be built and install ! '''Not all packages use the <code>configure; make; make install</code> system!
 
So let's take a look at a "standard" build function :
 
<pre>
build() {
   cd $startdir/src/$pkgname-$pkgver
   ./configure --prefix=/usr
   ./configure --prefix=/usr
   make || return 1
   make
  make prefix=$startdir/pkg/usr install
}
}
</pre>


What we do is :
Erklärung:
* enter the directory where sources were uncompressed :


  <pre>cd $startdir/src/$pkgname-$pkgver</pre>
* In das Verzeichnis der von ''makepkg'' entpackten Quelltexte wechseln (hier treten in der Praxis oft schon Probleme auf; besser, man schaut nach ob das Verzeichnis wirklich so heißt):
cd $pkgname-$pkgver # bei neueren makekpkg-Versionen muss nicht mehr explizit nach $srcdir gewechselt werden, aber es ist nich falsch, hier $srcdir/$pkgname-$pkgver zu verwenden.


But if you try to build your package, be carefull that this is the right directory : sometimes the uncompressed directory might be named differently :
* Konfigurieren des Paketes mit dem Installationsverzeichnis ''/usr'' und unter Umständen weiteren Optionen:
./configure --prefix=/usr --option1 --option2


  <pre>tar -xzf foo-0.99.tar.gz</pre>
Da die meisten Programme davon ausgehen, dass nach /usr/local installiert werden soll, wir unter Arch Linux aber nach /usr installieren wollen, ist es wichtig, das Prefix zu setzen.


and a <code>ls</code> might return :
* kompilieren:
make


  <pre>
Eine 'Standard' package-Funktion sieht so aus:
  .
  ..
  foo-0.99.tar.gz
  foo/</pre>


and not :
* installieren:
make DESTDIR=$pkgdir install


  <pre>
Dabei wird das Programm nicht in ''/usr'' sondern in ''$pkgdir/usr'' installiert, so dass erst einmal [[makepkg]] und indirekt auch [[pacman]] Kontrolle über die Dateien hat. Ob ''DESTDIR'' verwendet wird, hängt vom jeweiligen Programm bzw. dessen Makefile ab. Manchmal muss z.B. auch PREFIX verwendet und entsprechend umgebogen werden, und wenn Upstream es gar nicht auf die Reihe bekommt, muss auch ein manuelles Kopieren gewählt werden.
  .
  ..
  foo-0.99.tar.gz
  foo-0.99/</pre>


* configure the package, and tell it to install in the <code>/usr</code> directory :
make PREFIX=$pkgdir/usr install


  <pre>
=== Installationsdateien ===
  ./configure --prefix=/usr</pre>
Installationsdateien stellen die Möglichkeit bereit, Anweisungen vor oder nach der eigentlichen Installation auszuführen. Seitdem [[pacman]] Hooks verwenden kann, sind sie in einer Vielzahl von Fällen nicht mehr nötig und sollten dann auch vermieden werden. Dazu müssen sie im PKGBUILD angegeben werden, indem man die Variable install setzt. Unser Beispiel gibt 'foo.install' als Installationsdatei an. Es könnte z.B. folgendes enthalten:


* compile
post_install() {
/bin/true
}
post_upgrade() {
/bin/true
}
pre_remove() {
/bin/true
}


  <pre>
Erklärungen:
  make || return 1</pre>


* install the software but not in <code>/usr</code>, in <code>$startdir/pkg/usr</code> so that pacman has control of the files.
* '''post_install''': Wird nach der Installation ausgeführt. Es wird ein Argument übergeben:
** Die Paketversion
* '''post_upgrade''': Wird ausgeführt, nachdem alle Dateien aktualisiert wurden. Es werden zwei Argumente übergeben:
** Die neue Paketversion
** Die alte Paketversion
* '''pre_remove''': Wird ausgeführt, bevor Dateien gelöscht werden (beendet z.B. daemonen) und übergibt ein Argument:
** Die Paketversion


  <pre>
== Der Verzeichnisbaum der offiziellen Pakete ==
  make prefix=$startdir/pkg/usr install</pre>
Bei Arch Linux werden die PKGBUILDs, anhand derer die Pakete in den offiziellen Repositories gebaut sind, mit Subversion verwaltet. Darüber ist noch eine git-Infrastruktur mittels svntogit etabliert.


What we want to do is build the package not to install it, so instead of installing to the standard place (<code>/usr</code>), we tell <code>make</code> to put all files in our special directory : <code>$startdir/pkg/usr</code>. Thus, makepkg can look and see which files the package installs, and then compress them into the Arch package.
Will man die Gesamtheit aller Pakete auf den lokalen Rechner herunterladen oder aktualisieren, so kann dafür also [[subversion]] oder [[git]] verwendet werden.  


'''NOTE''': It is sometimes the case where <code>prefix</code> is not used in the <code>Makefile</code>; often <code>DESTDIR</code> is used instead. If the package is built with autoconf/automake, use <code>DESTDIR</code>, this is what is [http://sources.redhat.com/automake/automake.html#Install documented] in the manuals. Check if the generated <code>filelist</code> is a lot shorter than it should be, and if so, try building with <code>make DESTDIR=$startdir/pkg install</code>. If that does not work, you'll have to look further into the install commands that are executed by "<code>make <...> install=</code>".
Wir bitten jedoch darum, davon abzusehen. Die Repos sind groß, und die Bandbreite zu den Arch Linux Servern ist begrenzt. Außerdem wird auch viel Platz auf dem lokalen Dateisystem benötigt.  


==== The ABS tree====
== Erstellung von Paketen ==
{{achtung|Um Schäden am System zu vermeiden, sollten Pakete nie als root erstellt werden!}}
Pakete werden mit ''makepkg'' erstellt. Dazu muss in das Verzeichnis gewechselt werden, in dem sich das Paket befindet und hier ''makepkg'' ausgeführt werden. Verzeichnisse aus dem ABS-Verzeichnisbaum sollten zuvor woandershin, zum Beispiel nach ''/var/abs/local'' oder nach ~/paketierung kopiert werden und nicht zur Erstellung des Pakets benutzt werden.


When you run abs for the first time :
~/paketierung/foo/PKGBUILD (und ggf. noch weitere Dateien wie install-files, desktop-files, Patches u.v.m.


<pre>
Sind nicht alle Abhängigkeiten zum Bau vorhanden, listet ''makepkg'' diese auf. ''makepkg -s'' würde versuchen, sie zu installieren. Das funktioniert aber nur, wenn sie in einem Repo vorhanden sind, auf das die Datei [[pacman.conf]] referenziert.
root @ localhost # abs</pre>


it synchronizes what can be called "the ABS tree" whith the arch server using the cvs system. So what exactly is the ABS tree ? It is located under /var/abs and looks like this :
cd ~/paketierung/foo
makepkg
Jetzt entstehen ein Verzeichnis namens {{ic|src}}, und eines namens {{ic|pkg}}. In ersterem findet der Paketbau statt in letzerem landen die Dateien, die ins fertige Paket sollen. Im PKGBUILD kann mit $srcdir bzw. $pkgdir darauf zugegriffen werden.
~/paketierung/foo/PKGBUILD
                  src
                  pkg


<pre>
Das erstellte Paket (oder je nach Konfiguration der Variablen PKGDEST in der [[makepkg.conf]] ein Link darauf) befindet sich jetzt im selben Verzeichnis und kann mit [[pacman]] installiert werden:
|-
pacman -U foo-0.99-x86_64.pkg.tar.zst
| -- base/
|-
|    ||-- autoconf/
|-
|    ||-- automake/
|-
|    ||-- ...
|-
| -- devel/
|-
| -- ...
|-
| -- extra/
|-
|      || -- deamons/
|-
|      ||      || -- acpid/
|-
|      ||      ||      || -- PKGBUILD
...   ...    ...    ...
</pre>


So the ABS tree has exactly the same structure as the package database :
== Konfiguration ==
* first level directory represent categories
* second level directories represent the packages
* PKGBUILD files contains every information needed concerning the package


However, there is one special directory : '''local'''. This directory is ''yours'', this is where you'll do everything : you should never modify the rest of the tree.
=== makepkg.conf ===
{{achtung|Viele Änderungen in makepkg.conf können Probleme und Fehler in den Paketen nach sich ziehen und sollten daher nur von erfahreneren Nutzern durchgeführt werden. Dies betrifft nicht Änderungen wie den PACKAGER und seine E-Mail-Adresse.}}
In der Datei ''/etc/makepkg.conf'' werden die Eigenschaften von ''makepkg'' festgelegt. Dabei lassen sich die Standardeinstellungen der Programme verändern, die ''makepkg'' verwendet, um Pakete zu erstellen.
Zu nennen sind dabei die Umgebungsvariablen MAKEFLAGS, CFLAGS und CXXFLAGS, die ''gcc'' und ''make'' beeinflussen.


NOTE: The first download of the abs tree is the biggest, then only minor updates are needed, so don't be afraid about the data to download if you've got only a 56k connection : it's only text files and it's compressed during the transfer''
==Hinzufügen von Patches==
Hier wird beschrieben wie man einen Patch den man selbst erstellt oder heruntergeladen hat, in die {{ic|prepare ()}} Funktion einer {{ic|PKGBUILD}} Datei einpflegt.


Now that you know what the ABS tree is, how can we use it ?
Als erstes fügt man einen Eintrag für den Patch in die {{ic|source}} Zeile ein. Dieser Eintrag muss durch ein Leerzeichen von dem URL zur Originalquelle getrennt sein.
Ist der Patch im Internet verfügbar, trägt man den vollständigen URL zum Patch ein, der Patch wird dann später beim eigentlichen Kompilieren des Paketes automatisch heruntergeladen und im src Verzeichnis abgelegt. Hat man den Patch selbst erstellt, oder bereits vorher heruntergeladen, legt man ihn im selben Verzeichnis wie die {{ic|PKGBUILD}} Datei ab. In diesem Fall trägt man lediglich den Dateinamen des Patches in die {{ic|source}} Zeile ein. Der Patch wird dann automatisch in das {{ic|source}} Verzeichnis kopiert. Sollte man die {{ic|PKGBUILD}} Datei weitergeben wollen, so muss man sie mit der Patchdatei zusammen weitergeben.
Anschließend fügt man einen Eintrag zur {{ic|md5sums}} bzw. {{ic|sha1sums}} Zeile hinzu. Die Prüfsummen erstellt man mittels {{ic|makepkg -g}}.
Nun erstellt man die {{ic|prepare()}} Funktion. Um das Patchen zu automatisieren trägt man die Anweisung in das zu patchende Verzeichnis zu wechseln ein; z.B.
cd $srcdir/$pkgname-$pkgver
oder ähnlich. {{ic|$pkname-$pkgver}} ist oftmals, aber nicht immer, der Name des beim Entpacken einer heruntergeladenen Quelldatei erstellten Verzeichnisses.
Abschließend muss man noch dafür sorgen, dass der Patch aus dem angegebenen Verzeichnis heraus appliziert werden kann. Dies geschieht, indem man
patch -p1 -i $srcdir/pkgname.patch
in die {{ic|prepare()}} Funktion einträgt. Für {{ic|pkgname.patch}} setzt man hier den zuvor in die {{ic|source}} Zeile eingetragenen Dateinamen des Patches ein.
Hier ein zur Veranschaulichung ein Beispiel für eine {{ic|prepare}} Funktion mit Patchfunktion:
prepare() {
cd "${srcdir}/${pkgname}-${pkgver}"
sed 's/file_handle/file_handle_rofl/g' -i istream.*
patch -p1 -i ../https-segfault.patch
patch -p1 -1 ../w3m-bdwgc72.diff
}


==== First use of ABS : customizing a package====
Das Paket kann nun in gewohnter Weise gebaut werden.


This situation can arise more often than you may think : official packages are compiled choosing a certain number of <code>--enable</code> or <code>--disable</code> options, and these are not necessarily the ones you would have chosen.
== Siehe auch ==
* [[pacman]]
* [[AUR]]
* [[:en:Patching_in_ABS|Patching in ABS]] {{Sprache|en}}


To illustrate it, I'll take an example : ''foo'' The ''foo'' package is built with '''arts''' support disabled. Imagine that we want to enable '''arts'''. Here is how to do it :
== Weblinks ==
* find where is the ''foo'' package located. you can do this by :
* [http://www.gnu.org/software/make/manual/html_node/Options-Summary.html#Options-Summary Informationen über MAKEFLAGS] {{sprache|en}}
* [http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Option-Summary.html#Option-Summary Informationen über CFLAGS und CXXFLAGS] {{sprache|en}}
* [http://en.gentoo-wiki.com/wiki/Safe_Cflags Gentoo Wiki: Safe CFLAGS] {{sprache|en}}


search for ''foo'' at [http://archlinux.org/packages.php]
{{ÜberFDL||Seite=http://wiki.archlinux.org|Name=ArchLinux.org Wiki|Original=http://wiki.archlinux.org/index.php?title=ABS_-_The_Arch_Build_System}}
use the find command :


  <pre>
[[Kategorie:Paketverwaltung]]
  find /var/abs -name "foo"</pre>
[[en:Arch Build System]]
 
use the slocate command :
 
  <pre>
  slocate foo | grep ^/var/abs</pre>
 
In any case, you'll find that foo is part of <code>extra</code> and <code>multimedia</code> (for example)
 
* copy the ''foo'' <code>PKGBUILD</code> file to <code>/var/abs/local/foo</code>
 
  <pre>
  mkdir /var/abs/local/foo
  cp /var/abs/extra/multimedia/foo/* /var/abs/local/foo
  cd /var/abs/local/foo</pre>
 
* modify the <code>PKGBUILD</code> file : we'll add support for '''arts''' :
 
  <pre>
  build() {
    cd $startdir/src/$pkgname-$pkgver
    ./configure --prefix=/usr
    make || return 1
    make prefix=$startdir/pkg/usr install
  }</pre>
 
becomes :
 
  <pre>
  build() {
    cd $startdir/src/$pkgname-$pkgver
    ./configure --enable-arts --prefix=/usr
    make || return 1
    make prefix=$startdir/pkg/usr install
  }</pre>
 
* launch <code>makepkg</code> :
 
  <pre>
  makepkg</pre>
 
* install the new package using one of the following commands (<code>-A</code> for install, <code>-U</code> to upgrade an already installed package):
 
  <pre>
  pacman -A foo-*.pkg.tar.gz
  pacman -U foo-*.pkg.tar.gz</pre>
 
==== Compiler Flags and Customizing makepkg====
 
The configuration file for <code>makepkg</code> is <code>/etc/makepkg.conf</code>.  Here you can set environment variables for <code>gcc</code> and <code>make</code>, as well as some for <code>makepkg</code> itself.  The following is an example of <code>/etc/makepkg.conf</code>.
 
<pre>
# The FTP/HTTP download utility that makepkg will use to acquire sources
export FTPAGENT="/usr/bin/wget --continue --passive-ftp --tries=3 --waitretry=3"
 
# Information passed to gcc about what type of computer this is.
export CARCH="i686"
export CHOST="i686-pc-linux-gnu"
 
# Flags passed to gcc when a package is being compiled
export CFLAGS "-march athlon-tbird -O2 -pipe"
export CXXFLAGS "-march athlon-tbird -02 -pipe"
 
# Flags passed to make when a package is being compiled
export MAKEFLAGS="-j 2"
 
# Enable colorized output messages
export USE_COLOR="y"
 
# The remaining variables only affect the behavior of makepkg
# Enable fakeroot for building packages as a non-root user.
# See 'man fakeroot' for more information on fakeroot
export USE_FAKEROOT="y"
 
# The directory where all packages will be placed (default is ./)
export PKGDEST=/home/packages
 
# Base of the ABS tree (default is /var/abs)
export ABSROOT=/var/abs
 
# Set this if you want your name to show up in the packages you build
export PACKAGER="John Doe <nowhere@microsoft.com>"
</pre>
 
A word of caution: Users should be sure of any changes they may make to the variables <code>CFLAGS</code>, <code>CXXFLAGS</code>, and <code>MAKEFLAGS</code> as they can cause packages to be unstable or impossible to compile.  Also, the average Arch Linux user will not need to change the values for <code>CARCH</code>, <code>CHOST</code>, and <code>USE_FAKEROOT</code>.
 
References for gcc and make flags
* [http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Option-Summary.html#Option-Summary]
* [http://www.gnu.org/software/make/manual/html''chapter/make''9.html#SEC102]
 
==== Other uses of ABS====
 
Well here are two more wiki pages, whose goal is to go deeper in ABS :
* [[The Arch package making HOW-TO - with guidelines]]
* [[Custom local repository with ABS and gensync]]

Aktuelle Version vom 8. April 2020, 13:56 Uhr

Dieser Artikel wurde als veraltet markiert, und sollte kontrolliert, und gegebenfalls korrigiert bzw. aktualisiert werden.

Achtung: Mit Wirkung vom 16.05.2017 existiert das Paket extra/abs nicht mehr. Die neue offizielle Alternative heißt asp. Bitte beachtet in diesem Zusammenhang die Manpage.


Das Arch Build System (ABS) wird genutzt um:

  • Neue Pakete für Software zu erstellen
  • Vorhande Pakete an die eigenen Bedürfnisse anzupassen

Das Arch Build System besteht aus einem Werkzeug zum Herunterladen der PKGBUILDS (offiziell asp, alternativ z.B. pbget), makepkg und pacman. Dieser Artikel versucht nun eine Übersicht über das Erstellen von Paketen unter Archlinux zu geben. Detailreichere Informationen finden sich in den jeweiligen Manpages.

Vorbereitung

Man benötigt ein Tool, um das oder die PKGBUILDS, an denen man interessiert ist, herunter zu laden. Dazu kann man das Paket asp installieren: 

pacman -S asp

Dieses Paket wendet sich allerdings weniger an den gelegentlichen Paketersteller als an den Arch Linux Entwickler oder TU. Das erkennt man daran, dass die Pakete in einer Verzeichnisstruktur heruntergeladen werden, die der entspricht, die auf den offizellen Entwicklungsserver vorliegt. Ein Beispiel 

asp checkout emacs

erzeugt ein Verzeichnis /var/tmp/emacs und darunter 

$ ls -lR /var/tmp/emacs
/var/tmp/emacs:
nsgesamt 8
drwxr-xr-x 4 haawda users 4096  3. Sep 01:03 repos
drwxr-xr-x 2 haawda users 4096  3. Sep 01:03 trunk
/var/tmp/emacs/repos:
insgesamt 8
drwxr-xr-x 2 haawda users 4096  3. Sep 01:03 extra-i686
drwxr-xr-x 2 haawda users 4096  3. Sep 01:03 extra-x86_64
/var/tmp/emacs/repos/extra-i686:
insgesamt 4
-rw-r--r-- 1 haawda users 1546  3. Sep 01:03 PKGBUILD
/var/tmp/emacs/repos/extra-x86_64:
insgesamt 4
-rw-r--r-- 1 haawda users 1546  3. Sep 01:03 PKGBUILD
/var/tmp/emacs/trunk:
insgesamt 4
-rw-r--r-- 1 haawda users 1546  3. Sep 01:03 PKGBUILD

Das ist eine Struktur, mit der der gelegentliche Paketersteller vermutlich nicht arbeiten will. Hier bietet sich an, auf ein Tool wie pbget zurückzugreifen. pbget ist dem Ursprung nach eher ein AUR-Helper, kann aber auch offizielle PKGBUILDS herunterladen. 

pbget emacs

z.B. erzeugt im aktuellen Verzeichnis ein Unterverzeichnis mit den Dateien, die man zur Erzeugung des offiziellen emacs-Paketes braucht. Das ist erheblich einfacher zu durchschauen.

Alle sonstigen Pakete, die zur Erstellung von Paketen notwendig sind, befinden sich in der Gruppe base-devel: 

pacman -S base-devel

Das Paket

Ein Paket ist eine Datei, die der Namenskonvention foo.pkg.tar.zst entspricht.

Die Paketendung deutet es schon an: Es handelt sich um ein mit zstd komprimiertes tar-Archiv, das neben den eigentlichen Daten, die durch das Paket verwaltet werden sollen, noch folgendes enthält:

  • Die zu installierenden Dateien
  • .PKGINFO : enthält alle Metadaten, die pacman für den Umgang mit Paketen, Abhängigkeiten etc. benötigt.
  • .BUILDINFO : enthält weitere Metadaten über die Parameter, die beim Bau des Paketes aktiv waren, sowie eine Lister der zum Zeitpunkt des Bauens installierten Pakete.
  • .INSTALL : enthält Befehle, die nach dem Installieren/Aktualisieren/Deinstallieren ausgeführt werden. (Nur vorhanden, wenn es in PKGBUILD definiert wurde)

Das PKGBUILD

Ein PKGBUILD enthält die Bauanweisungen und Metadaten über ein Paket, das von pacman installierbar sein soll. Es stellt die Grundlage für Pakete in Archlinux dar. Ein PKGBUILD ist eine einfache Textdatei, die Bash-Code (die PKGBUILDs einfach aus der bash heraus aufzurufen schlägt aber fehl. Sie werden von makepkg eingebunden.) enthält und beispielsweise so aussehen kann: 

# $Id: PKGBUILD,v 1.12 2003/11/06 08:26:13 dorphell Exp $
# Maintainer: judd <jvinet@zeroflux.org>
# Contributor: Judd Vinet <jvinet@zeroflux.org>
pkgname=foo
pkgver=0.99 # note: if the pkgver had been '0.99-10' then use an underscore. like '0.99_10'
pkgrel=1
pkgdesc="short description of foo"
arch=(i686 x86_64)
url="http://www.foo.org"
license=('GPL')
groups=
provides=
depends=('qt' 'python')
makedepends=('guile')
conflicts=('yafoo')
replaces=('mffoo')
backup=('etc/foo/foo.conf')
install='foo.install'
source=(http://www.foo.org/download/$pkgname-$pkgver.tar.gz)
md5sums=('2c0cca3ef6330a187c6ef4fe41eca')

build() {
  cd $srcdir/$pkgname-$pkgver
  ./configure --prefix=/usr
  make
}
package() {
  cd $srcdir/$pkgname-$pkgver
  make DESTDIR=$pkgdir install
}

Erklärung:

  • # text : Kommentare
  • # $Id: PKGBUILD,v ... : Das SVN-Tag für dieses Paket (automatisch vom Archlinux-SVN System erstellt). Dies sollte bei Paketen, die für das AUR gedacht sind, stets weggelassen werden.
  • # Maintainer : Der Betreuer für dieses Paket
  • # Contributor : Jemand, der zu dem PKGBUILD darüber hinaus etwas beigetragen hat. Das kann zum Beispiel ein vorheriger Betreuer des Pakets sein.
  • pkgbase : Optional, bei Nichtangabe wird automatisch der erste Wert im Array $pkgname verwendet. Kommt nur bei Split packages zum Tragen.
  • pkgname : Der Paketname, kann alternativ auch ein Array sein (Split Packages)
  • pkgver : Die Paketversion
  • pkgrel : Die Releasenummer des Arch Paketes. Wird geändert, wenn das PKGBUILD verändert wurde oder (bei Paketen aus den Repos) das Paket neu gebaut werden musste.
  • pkgdesc : Eine Kurzbeschreibung des Paketes, zu sehen in der Paket Datenbank
  • arch : Die Architekturen, auf denen das Paket kompiliert und getestet wurde, oder 'any' bei plattformunabhängigen Paketen.
  • url : Die Homepage des Programmes
  • license : Die Lizenz, unter der das Programm steht
  • groups : Wird genutzt um Pakete zu Gruppen zusammen zu fassen. Wenn du z.B. KDE installieren willst, werden alle Pakete installiert, die zur Gruppe 'kde' gehören Liste der Gruppen
  • provides : Wird genutzt, wenn das Paket ein anderes Paket bereitstellt.
  • depends : Liste der Abhängigkeiten um das Programm auszuführen.
  • makedepends : Liste der Abhängigkeiten um das Programm zu kompilieren. Pakete, die schon unter depends aufgeführt wurden, sind hier nicht noch einmal aufzuführen.
  • conflicts : Pakete, die nicht zusammen mit diesem Programm installiert sein können. In unserem Fall steht foo in Konflikt zu yafoo.
  • replaces : Das neue Paket ersetzt das alte. In unserem Fall wird mffoo nicht mehr unterstützt und wird durch foo ersetzt.
  • backup : Dateien, die gesichert werden (als .pacsave), wenn das Programm deinstalliert wird.
  • install : Spezifiziert ein Installationsskript, das im Paket enthalten ist. (Muss sich mit PKGBUILD im selben Verzeichnis befinden)
  • source : Die Bezugsquelle(n) des Quelltextes. Kann sowohl ein lokales Paket, als auch ein remote "http" oder "ftp" Paket sein. Der Dateiname wird aus pkgname und pkgver erstellt, damit der Pfad nicht bei jeder neuen Version angepasst werden muss.
  • md5sums : MD5 Summen der Quelltexte um beschädigte Dateien auszuschließen.
  • build() : Alle Schritte, die nötig sind um den Quelltext zu übersetzen (optional). Die Schritte müssen mit normalen Benutzerrechte ausgeführt werden können.
  • package(): Alle Schritte, die nötig sind, um die nötigen Dateien ins eigentliche Paket zu übertragen.

Die Build-Funktion und die Package-Funktion

Neben der Build- und der Package-Funktion kann es auch noch eine Prepare- und eine Pkgver-Funktion geben. Die prepare-Funktion dient dazu, Anpassungen am eigentlichen Quelltext vorzunehmen, und sollte nur in Ausnahmefällen verwendet werden (ein Beispiel siehe unten). Die pkgver-Funktion dient zur automatischen Generierung einer Paketversion und kommt hauptsächlich zum Tragen, wenn die Quellcodes über ein VCS bezogen werden. Reihenfolge der Ausführung: 

prepare(){}
pkgver(){}
build(){}
package(){}

In der build-Funktion werden die Anweisungen ausgeführt, die nötig sind, um das Paket zu kompilieren. Sie kann entfallen (Binary-Blobs, Java-Jar-Files, Skripte).

In der package-Funktion werden die zu installierenden Dateien und Verzeichnisse so abgelegt, dass makepkg daraus einen Tarball - das Paket - erstellen kann, der dann von pacman installiert werden kann. In einem ersten Schritt geschieht die durch Anlegen eine Verzeichnisbaums namens 'pkg' (hirauf zeigt die Bash-Variable pkgdir). Es muss mindestens eine, kann aber auch mehrere Package-Funktionen geben. Bei mehreren package-Funktionen spricht man von Package Splitting.

Viele Pakete (nämlich die, die auf die Verwendung der GNU-Autotools hin ausgelegt sind) können über den Dreisatz erstellt werden: 

./configure --prefix=/usr
make
make install

./configure überprüft zunächst, ob alle Voraussetzungen für das zu kompilierende Programm erfüllt sind. Über dieses Script lässt sich auch konfigurieren, wie und mit welchen Funktionen ein Programm kompiliert wird. ./configure --help zeigt meistens eine Übersicht über die Optionen, die verfügbar sind. make kompiliert schließlich das Paket und make install installiert die Dateien.

Du solltest immer die INSTALL oder die README Datei des jeweiligen Pakets lesen, um zu erfahren, wie es erstellt und installiert werden sollte, denn nicht alle Pakete nutzen diesen Dreisatz! Bei neueren Build-Systemen (cmake, meson/ninja) ist es prinzipiell nicht anders, aber die Befehle des Dreisatz lauten anders.

Eine 'Standard', autotools-basierte build-Funktion sieht so aus: 

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

Erklärung:

  • In das Verzeichnis der von makepkg entpackten Quelltexte wechseln (hier treten in der Praxis oft schon Probleme auf; besser, man schaut nach ob das Verzeichnis wirklich so heißt):
cd $pkgname-$pkgver # bei neueren makekpkg-Versionen muss nicht mehr explizit nach $srcdir gewechselt werden, aber es ist nich falsch, hier $srcdir/$pkgname-$pkgver zu verwenden.
  • Konfigurieren des Paketes mit dem Installationsverzeichnis /usr und unter Umständen weiteren Optionen:
./configure --prefix=/usr --option1 --option2

Da die meisten Programme davon ausgehen, dass nach /usr/local installiert werden soll, wir unter Arch Linux aber nach /usr installieren wollen, ist es wichtig, das Prefix zu setzen.

  • kompilieren:
make

Eine 'Standard' package-Funktion sieht so aus:

  • installieren:
make DESTDIR=$pkgdir install

Dabei wird das Programm nicht in /usr sondern in $pkgdir/usr installiert, so dass erst einmal makepkg und indirekt auch pacman Kontrolle über die Dateien hat. Ob DESTDIR verwendet wird, hängt vom jeweiligen Programm bzw. dessen Makefile ab. Manchmal muss z.B. auch PREFIX verwendet und entsprechend umgebogen werden, und wenn Upstream es gar nicht auf die Reihe bekommt, muss auch ein manuelles Kopieren gewählt werden. 

make PREFIX=$pkgdir/usr install

Installationsdateien

Installationsdateien stellen die Möglichkeit bereit, Anweisungen vor oder nach der eigentlichen Installation auszuführen. Seitdem pacman Hooks verwenden kann, sind sie in einer Vielzahl von Fällen nicht mehr nötig und sollten dann auch vermieden werden. Dazu müssen sie im PKGBUILD angegeben werden, indem man die Variable install setzt. Unser Beispiel gibt 'foo.install' als Installationsdatei an. Es könnte z.B. folgendes enthalten: 

post_install() {
/bin/true
}

post_upgrade() {
/bin/true
}

pre_remove() {
/bin/true
}

Erklärungen:

  • post_install: Wird nach der Installation ausgeführt. Es wird ein Argument übergeben:
    • Die Paketversion
  • post_upgrade: Wird ausgeführt, nachdem alle Dateien aktualisiert wurden. Es werden zwei Argumente übergeben:
    • Die neue Paketversion
    • Die alte Paketversion
  • pre_remove: Wird ausgeführt, bevor Dateien gelöscht werden (beendet z.B. daemonen) und übergibt ein Argument:
    • Die Paketversion

Der Verzeichnisbaum der offiziellen Pakete

Bei Arch Linux werden die PKGBUILDs, anhand derer die Pakete in den offiziellen Repositories gebaut sind, mit Subversion verwaltet. Darüber ist noch eine git-Infrastruktur mittels svntogit etabliert.

Will man die Gesamtheit aller Pakete auf den lokalen Rechner herunterladen oder aktualisieren, so kann dafür also subversion oder git verwendet werden.

Wir bitten jedoch darum, davon abzusehen. Die Repos sind groß, und die Bandbreite zu den Arch Linux Servern ist begrenzt. Außerdem wird auch viel Platz auf dem lokalen Dateisystem benötigt.

Erstellung von Paketen

Achtung: Um Schäden am System zu vermeiden, sollten Pakete nie als root erstellt werden!

Pakete werden mit makepkg erstellt. Dazu muss in das Verzeichnis gewechselt werden, in dem sich das Paket befindet und hier makepkg ausgeführt werden. Verzeichnisse aus dem ABS-Verzeichnisbaum sollten zuvor woandershin, zum Beispiel nach /var/abs/local oder nach ~/paketierung kopiert werden und nicht zur Erstellung des Pakets benutzt werden. 

~/paketierung/foo/PKGBUILD (und ggf. noch weitere Dateien wie install-files, desktop-files, Patches u.v.m.

Sind nicht alle Abhängigkeiten zum Bau vorhanden, listet makepkg diese auf. makepkg -s würde versuchen, sie zu installieren. Das funktioniert aber nur, wenn sie in einem Repo vorhanden sind, auf das die Datei pacman.conf referenziert. 

cd ~/paketierung/foo
makepkg

Jetzt entstehen ein Verzeichnis namens src, und eines namens pkg. In ersterem findet der Paketbau statt in letzerem landen die Dateien, die ins fertige Paket sollen. Im PKGBUILD kann mit $srcdir bzw. $pkgdir darauf zugegriffen werden. 

~/paketierung/foo/PKGBUILD
                  src
                  pkg

Das erstellte Paket (oder je nach Konfiguration der Variablen PKGDEST in der makepkg.conf ein Link darauf) befindet sich jetzt im selben Verzeichnis und kann mit pacman installiert werden: 

pacman -U foo-0.99-x86_64.pkg.tar.zst

Konfiguration

makepkg.conf

Achtung: Viele Änderungen in makepkg.conf können Probleme und Fehler in den Paketen nach sich ziehen und sollten daher nur von erfahreneren Nutzern durchgeführt werden. Dies betrifft nicht Änderungen wie den PACKAGER und seine E-Mail-Adresse.

In der Datei /etc/makepkg.conf werden die Eigenschaften von makepkg festgelegt. Dabei lassen sich die Standardeinstellungen der Programme verändern, die makepkg verwendet, um Pakete zu erstellen. Zu nennen sind dabei die Umgebungsvariablen MAKEFLAGS, CFLAGS und CXXFLAGS, die gcc und make beeinflussen.

Hinzufügen von Patches

Hier wird beschrieben wie man einen Patch den man selbst erstellt oder heruntergeladen hat, in die prepare () Funktion einer PKGBUILD Datei einpflegt.

Als erstes fügt man einen Eintrag für den Patch in die source Zeile ein. Dieser Eintrag muss durch ein Leerzeichen von dem URL zur Originalquelle getrennt sein. Ist der Patch im Internet verfügbar, trägt man den vollständigen URL zum Patch ein, der Patch wird dann später beim eigentlichen Kompilieren des Paketes automatisch heruntergeladen und im src Verzeichnis abgelegt. Hat man den Patch selbst erstellt, oder bereits vorher heruntergeladen, legt man ihn im selben Verzeichnis wie die PKGBUILD Datei ab. In diesem Fall trägt man lediglich den Dateinamen des Patches in die source Zeile ein. Der Patch wird dann automatisch in das source Verzeichnis kopiert. Sollte man die PKGBUILD Datei weitergeben wollen, so muss man sie mit der Patchdatei zusammen weitergeben. Anschließend fügt man einen Eintrag zur md5sums bzw. sha1sums Zeile hinzu. Die Prüfsummen erstellt man mittels makepkg -g. Nun erstellt man die prepare() Funktion. Um das Patchen zu automatisieren trägt man die Anweisung in das zu patchende Verzeichnis zu wechseln ein; z.B. 

cd $srcdir/$pkgname-$pkgver

oder ähnlich. $pkname-$pkgver ist oftmals, aber nicht immer, der Name des beim Entpacken einer heruntergeladenen Quelldatei erstellten Verzeichnisses. Abschließend muss man noch dafür sorgen, dass der Patch aus dem angegebenen Verzeichnis heraus appliziert werden kann. Dies geschieht, indem man 

patch -p1 -i $srcdir/pkgname.patch

in die prepare() Funktion einträgt. Für pkgname.patch setzt man hier den zuvor in die source Zeile eingetragenen Dateinamen des Patches ein. Hier ein zur Veranschaulichung ein Beispiel für eine prepare Funktion mit Patchfunktion: 

prepare() {
cd "${srcdir}/${pkgname}-${pkgver}"
sed 's/file_handle/file_handle_rofl/g' -i istream.*
patch -p1 -i ../https-segfault.patch 
patch -p1 -1 ../w3m-bdwgc72.diff
}

Das Paket kann nun in gewohnter Weise gebaut werden.

Siehe auch

Weblinks


Dieser Artikel (oder Teile davon) steht unter GNU FDL (GNU Freie Dokumentationslizenz) und ist eine Übersetzung aus dem ArchLinux.org Wiki. Am Original-Artikel kann jeder Korrekturen und Ergänzungen vornehmen. Im ArchLinux.org Wiki ist eine Liste der Autoren verfügbar.

Abgerufen von „https://wiki.archlinux.de/index.php?title=Arch_Build_System&oldid=21640“