Arch Build System: Unterschied zwischen den Versionen
Wtfoo (Diskussion | Beiträge) |
Wtfoo (Diskussion | Beiträge) |
||
Zeile 135: | Zeile 135: | ||
==== Die build Funktion==== | ==== Die build Funktion==== | ||
Wenn du dich nicht mit dem Bauen von Paketen auskennst, solltest du wissen, dass die meisten Pakete über den 'Dreisatz' | 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 : | * Paketdateien dekomprimieren : | ||
Zeile 163: | Zeile 163: | ||
<pre>make install</pre> | <pre>make install</pre> | ||
Du solltest immer die <code>INSTALL</code> Datei lesen, um zu erfahren, wie das Paket | Du solltest immer die <code>INSTALL</code> 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 | Schauen wir uns eine 'standart' build Funktion an : | ||
<pre> | <pre> | ||
Zeile 176: | Zeile 176: | ||
</pre> | </pre> | ||
Im Detail : | |||
* In das Verzeichnis der entpackten Quelltexte wechseln : | * In das Verzeichnis der entpackten Quelltexte wechseln : | ||
Zeile 196: | Zeile 196: | ||
make prefix=$startdir/pkg/usr install</pre> | make prefix=$startdir/pkg/usr install</pre> | ||
Wir wollen das Paket erstellen, aber nicht installiren, also installieren wir es nicht standartmäßig (<code>/usr</code>), sondern nach <code>$startdir/pkg/usr</code>. So kann makepkg sehen, welche Dateien das Paket installiert und daraus ein Arch Paket erstellen. | |||
''' | '''BEACHTE''': Teilweise wird <code>prefix</code> nicht im <code>Makefile</code> genutzt; meist wird stattdessen <code>DESTDIR</code> verwendet. Wenn das Paket mit Hilfe von autofoo (autoconf/automake) erstellt wird, solltest du <code>DESTDIR</code> nutzen, denn so wird es in der [http://sources.redhat.com/automake/automake.html#Install Dokumentation] angegeben. Überprüfe, ob die generierte <code>filelist</code> um einiges kürzer ist, als sie sein sollte. Ist dies der Fall, versuche das Paket mit <code>make DESTDIR=$startdir/pkg install</code> zu erstellen. | ||
Fall auch das nicht funktioniert, wirst du dir die Befehle, die "<code>make <...> install=</code>" ausführt genauer anschauen müssen. | |||
==== The ABS tree==== | ==== The ABS tree==== |
Version vom 8. August 2006, 18:25 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
Um ABS zu nutzen, musst du zuerst die Programme "cvsup" und "wget" installieren:
pacman -Sy cvsup wget
Oder, wenn du die Pakete z.B. im Verzeichnis 'foo' gespeichert hast:
cd foo pacman -A cvsup-*.pkg.tar.gz wget-*.pkg.tar.gz
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
- .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?
Wie schon gesagt, enthält PKGBUILD die Metadaten über ein Paket. Es ist eine einfache Textdatei, die z.B. so aussehen könnte:
# $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() { 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
- 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 drei Zeilen am Ende jeder Installationsdatei vorhanden sein.
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 :
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
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 'standart' build Funktion an :
build() { cd $startdir/src/$pkgname-$pkgver ./configure --prefix=/usr make || return 1 make prefix=$startdir/pkg/usr install }
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 installiren, also installieren wir es nicht standartmäß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.
Fall auch das nicht funktioniert, wirst du dir die Befehle, die "make <...> install=
" ausführt genauer anschauen müssen.
The ABS tree
When you run abs for the first time :
root @ localhost # abs
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 :
|- | -- base/ |- | ||-- autoconf/ |- | ||-- automake/ |- | ||-- ... |- | -- devel/ |- | -- ... |- | -- extra/ |- | || -- deamons/ |- | || || -- acpid/ |- | || || || -- PKGBUILD ... ... ... ...
So the ABS tree has exactly the same structure as the package database :
- 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.
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
Now that you know what the ABS tree is, how can we use it ?
First use of ABS : customizing a package
This situation can arise more often than you may think : official packages are compiled choosing a certain number of --enable
or --disable
options, and these are not necessarily the ones you would have chosen.
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 :
- find where is the foo package located. you can do this by :
search for foo at [1] use the find command :
find /var/abs -name "foo"
use the slocate command :
slocate foo | grep ^/var/abs
In any case, you'll find that foo is part of extra
and multimedia
(for example)
- copy the foo
PKGBUILD
file to/var/abs/local/foo
mkdir /var/abs/local/foo cp /var/abs/extra/multimedia/foo/* /var/abs/local/foo cd /var/abs/local/foo
- modify the
PKGBUILD
file : we'll add support for arts :
build() { cd $startdir/src/$pkgname-$pkgver ./configure --prefix=/usr make || return 1 make prefix=$startdir/pkg/usr install }
becomes :
build() { cd $startdir/src/$pkgname-$pkgver ./configure --enable-arts --prefix=/usr make || return 1 make prefix=$startdir/pkg/usr install }
- launch
makepkg
:
makepkg
- install the new package using one of the following commands (
-A
for install,-U
to upgrade an already installed package):
pacman -A foo-*.pkg.tar.gz pacman -U foo-*.pkg.tar.gz
Compiler Flags and Customizing makepkg
The configuration file for makepkg
is /etc/makepkg.conf
. Here you can set environment variables for gcc
and make
, as well as some for makepkg
itself. The following is an example of /etc/makepkg.conf
.
# 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>"
A word of caution: Users should be sure of any changes they may make to the variables CFLAGS
, CXXFLAGS
, and MAKEFLAGS
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 CARCH
, CHOST
, and USE_FAKEROOT
.
References for gcc and make flags
Other uses of ABS
Well here are two more wiki pages, whose goal is to go deeper in ABS :