Arch Build System: Unterschied zwischen den Versionen
Boenki (Diskussion | Beiträge) Vorlage 'ÜberFDL' eingebaut |
Boenki (Diskussion | Beiträge) K typo |
||
Zeile 24: | Zeile 24: | ||
pacman -S base-devel | pacman -S base-devel | ||
== Was ist ein Paket ? == | == Was ist ein Paket? == | ||
Ein Paket ist eine Datei, die meist ''foo''.pkg.tar.gz genannt ist. | Ein Paket ist eine Datei, die meist ''foo''.pkg.tar.gz genannt ist. |
Version vom 3. Januar 2009, 20:17 Uhr
Einführung
Das Arch Build System (ABS) wird genutzt um:
- Neue Pakete für Software zu erstellen, für die noch keine Pakete vorhanden sind
- 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.
Vorbereitung
Das Paket "abs" installieren:
pacman -S abs
Zusätzlich noch wget:
pacman -S wget
Alternativ kannst Du auch komplett die Gruppe base-devel installieren. Dies beinhaltet abs und auch andere nützliche Tools zum Bauen von Paketen.
pacman -S base-devel
Was ist ein Paket?
Ein Paket ist eine Datei, die meist foo.pkg.tar.gz genannt ist.
Es ist nicht mehr, als ein gz komprimiertes tar-Archiv, das 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.
- .FILELIST : enthält alle Dateien des Archives. Nötig um ein Paket zu deinstallieren oder um ggf. Abhängigkeitskonflikte festzustellen (ab Pacman 3.1 sind Filelisten nicht mehr nötig und werden vom entsprechenden makepkg auch nicht mehr erzeugt)
- .INSTALL : enthält Befehle, die nach dem Installieren/Upgraden/Deinstallieren ausgeführt werden. (Nur vorhanden, wenn es in PKGBUILD definiert wurde)
Was ist PKGBUILD und was enthält es?
PKGBUILD enthält die Metadaten über ein Paket. Es ist eine einfache Textdatei, die z.B. 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=('2c0cca3ef6330a187c6ef4fe41ecaa4d35175bee593a7cc7d6205584a94d8625') build() { cd $startdir/src/$pkgname-$pkgver ./configure --prefix=/usr make || return 1 make prefix=$startdir/pkg/usr install }
Erklärung für jede Zeile:
- # text : Kommentare
- # $Id: PKGBUILD,v ... : Das CVS-Tag für dieses Paket (Vom Archlinux-CVS System erstellt).
- # Maintainer : Der Verantwortliche für dieses Paket in den offiziellen Repo's.
- # Contributor : Der Verfasser der ersten PKGBUILD für dieses Paket.
- pkgname : Der Paketname
- pkgver : Die Paketversion
- pkgrel : Die Releasenummer des Arch Paketes. Wird geändert, wenn das PKGBUILD verändert wurde, sie unterscheided sich also von der Paketversion.
- pkgdesc : Eine Kurzbeschreibung des Paketes. Du siehst sie, in der Paket Datenbank
- arch : Die Architekturen, auf denen das Paket kompiliert und getestet wurde.
- 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
- provides : Wird genutzt, wenn das Paket ein anderes Paket enthält. z.B. enthält 'kernel-scsi' 'kernel'
- depends : Liste der Abhängigkeiten um das Programm auszuführen.
- makedepends : Liste der Abhängigkeiten um das Programm zu kompilieren.
- conflicts : Pakete, die nicht zusammen mit diesem Programm installiert sein können. In unserem Fall steht foo in Konflikt zu yafoo (yet another foo).
- replaces : Das neue Paket ersetzt das Alte. In unserem Fall wird mffoo (my first foo) 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 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.
Nun die Funktionen:
- build : Alle Schritte, die nötig sind um das Paket zu kompilieren. (Darauf gehen wir später besser ein).
Wie du siehst, enthält PKGBUILD alle Informationen, die von der Paketverwaltung gebraucht werden könnten. Es ist das Herzstück von pacman und ABS.
Es sind auch Installationsdateien vorhanden. Unser PKGBUILD 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 } op=$1 shift $op "$@"
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
Damit die Installationsdateien funktionieren, müssen diese letzten drei Zeilen am Ende jeder Installationsdatei vorhanden sein.
Schablonen sowohl für ein PKGBUILD als auch für Installationsdateien befinden sich auf deinem Rechner, z.B. unter /var/abs/core. Sie haben .proto als Suffix.
Die build Funktion
Wenn du dich nicht mit dem Bauen von Paketen auskennst, solltest du wissen, dass die meisten Pakete über den 'Dreisatz' erstellt werden können:
- Paketdateien dekomprimieren (macht in den meisten Fällen makepkg):
tar -xzf foo-0.99.tar.gz tar -xjf foo-0.99.tar.bz2
- In das Verzeichnis wechseln
cd foo-0.99
- configure (1/3): normalerweise ist ein kleines Script
configure
im Quelltextverzeichniss vorhanden. Es wird genutzt um das Paket zu konfigurieren (hinzufügen von Unterstützungen, Installationsverzeichnis festlegen, ...) und sicher zu stellen, dass alle Abhängigkeiten aufgelöst sind.
./configure [[option]]
Du solltest zuerst einen Blick in die 'help' Option werfen:
./configure --help
- make (2/3) : Kompilieren der Quelltexte
make
- install (3/3)
make install
Du solltest immer die INSTALL
oder die <README> Datei lesen, um zu erfahren, wie das Paket erstellt und installiert werden sollte , denn nicht alle Pakete nutzen den Dreisatz 'configure; make; make install'!
Schauen wir uns eine 'standard' build Funktion an :
build() { cd $startdir/src/$pkgname-$pkgver ./configure --prefix=/usr make || return 1 make prefix=$startdir/pkg/usr install || return 1 }
Im Detail :
- In das Verzeichnis der entpackten Quelltexte wechseln :
cd $startdir/src/$pkgname-$pkgver
- Konfigurieren des Paketes mit dem Installationsverzeichnis
/usr
:
./configure --prefix=/usr
- compile
make || return 1
- installiere das Programm nicht in
/usr
sondern in$startdir/pkg/usr
, sodass pacman Kontrolle über die Dateien hat :
make prefix=$startdir/pkg/usr install
Wir wollen das Paket erstellen, aber nicht installieren, also installieren wir es nicht standardmäßig (/usr
), sondern nach $startdir/pkg/usr
. So kann makepkg sehen, welche Dateien das Paket installiert und daraus ein Arch Paket erstellen.
BEACHTE: Teilweise wird prefix
nicht im Makefile
genutzt; meist wird stattdessen DESTDIR
verwendet. Wenn das Paket mit Hilfe von autofoo (autoconf/automake) erstellt wird, solltest du DESTDIR
nutzen, denn so wird es in der Dokumentation angegeben. Überprüfe, ob die generierte filelist
um einiges kürzer ist, als sie sein sollte. Ist dies der Fall, versuche das Paket mit make DESTDIR=$startdir/pkg install
zu erstellen.
Falls auch das nicht funktioniert, wirst du dir die Befehle, die "make <...> install=
" ausführt genauer anschauen müssen.
Moderne Skriptsprachen kommen oft auch mit modernen Buildsystemen. Da kann die Buildfunktion auch völlig anders aussehen.
Der ABS Verzeichnisbaum
Wenn du abs das erste Mal nutzt :
root @ localhost # abs
so synchronisierst du deinen "ABS Verzeichnisbaum" mit einem Arch Server über das CVS-System.
Was genau ist der ABS Verzeichnisbaum? Er befindet sich in /var/abs
und sieht so aus :
|- | -- base/ |- | ||-- autoconf/ |- | ||-- automake/ |- | ||-- ... |- | -- devel/ |- | -- ... |- | -- extra/ |- | || -- deamons/ |- | || || -- acpid/ |- | || || || -- PKGBUILD ... ... ... ...
Also ist der ABS Verzeichnisbaum genauso aufgebaut, wie die Paketdatenbank :
- erste Verzeichnisebene: Kategorien
- zweite Verzeichnisebene: Paketverzeichnisse
- PKGBUILD Dateien mit Paketinformationen
Allerdings gibt es ein spezielles Verzeichnis: local. Es ist dein Verzeichnis, in dem du Pakete erstellst, du solltest niemals etwas in den restlichen Verzeichnissen ändern.
BEACHTE: Der erste Download des ABS Verzeichnisbaumes ist der größte, danach sind nur kleinere Updates nötig. Du brauchst auch mit kleinerer Bandbreite oder Volumentarif keine Angst haben : es sind nur Textdateien, die bei der Übertragung auch noch komprimiert sind.
Nun weißt du, was der ABS Verzeichnisbaum ist, aber wie nutzt man ihn?
Erste Verwendung von ABS : Anpassen von Paketen
Diese Situation kann öfter erscheinen, als man meint : offizielle Pakete sind mit --enable
oder --disable
Optionen erstellt, die nicht deinen Anforderungen entsprechen.
Nehmen wir als Beispiel : foo Das Paket foo wurde mit deaktivierte arts Unterstützung erstellt. Um arts Unterstützung zu aktivieren muss folgendes getan werden :
- finde heraus, wo das Paket foo liegt :
suche foo in [1]
per find :
find /var/abs -name "foo"
per slocate :
slocate foo | grep ^/var/abs
In jedem Fall wirst du sehen, dass foo Bestandteil von extra
und multimedia
ist (Beispiel).
- kopiere das foo
PKGBUILD
in dein Arbeitsverzeichnis/var/abs/local/foo
mkdir /var/abs/local/foo cp /var/abs/extra/multimedia/foo/* /var/abs/local/foo cd /var/abs/local/foo
- Anpassung des
PKGBUILD
: In unserem Fall arts Unterstützung :
build() { cd $startdir/src/$pkgname-$pkgver ./configure --prefix=/usr make || return 1 make prefix=$startdir/pkg/usr install }
wird zu :
build() { cd $startdir/src/$pkgname-$pkgver ./configure --enable-arts --prefix=/usr make || return 1 make prefix=$startdir/pkg/usr install }
- Paket erstellen :
makepkg
- Paket installieren (
-A
zum installieren,-U
zum upgraden eines installierten Paketes, wobei-A
nicht mehr empfohlen wird):
pacman -A foo-*.pkg.tar.gz pacman -U foo-*.pkg.tar.gz
Tuning: Compiler Flags und Anpassung von makepkg
Die Konfigurationsdatei von makepkg
liegt in /etc/makepkg.conf
. Hier kannst du Umgebungsvariablen sowohl für gcc
und make
als auch für makepkg
selbst definieren. Hier eine Beispiel /etc/makepkg.conf
:
# Das FTP/HTTP download Programm, das makepkg zum laden der Quelltexte nutzt export FTPAGENT="/usr/bin/wget --continue --passive-ftp --tries=3 --waitretry=3" # Informationen für GCC über den Prozessortyp export CARCH="i686" export CHOST="i686-pc-linux-gnu" # Flags für GCC, wenn ein Paket kompiliert wird export CFLAGS "-march athlon-tbird -O2 -pipe" export CXXFLAGS "-march athlon-tbird -02 -pipe" # Flags für make, wenn ein Paket kompiliert wird export MAKEFLAGS="-j 2" # Aktiviere farbige Ausgabe export USE_COLOR="y" ## Folgende Variablen betreffen nur makepkg # Aktiviere fakeroot um Pakete als normaler User zu erstellen export USE_FAKEROOT="y" # Das Verzeichnis, in dem das erstellte Paket erstellt wird (normalerweise ./) export PKGDEST=/home/packages # Pfad zum ABS Verzeichnisbaum (normalerweise /var/abs) export ABSROOT=/var/abs # Aktiviere dies, um deinen Namen in erstellte Pakete zu schreiben export PACKAGER="John Doe <nowhere@devnull.com>"
BEACHTE: User wissen, was die Änderungen an den CFLAGS, CXXFLAGS, MAKEFLAGS
Variablen bewirken, da sie Unstabilität oder Fehler bewirken können. Außerdem sollte der normale Arch Linux User die Werte für CARCH
und USE_FAKEROOT
nicht ändern.
Referenzen zu gcc und make flags:
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. |