Arch Build System

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. in den Ordner 'foo' gedownloaded hast:

cd foo
pacman -A  cvsup-*.pkg.tar.gz  wget-*.pkg.tar.gz

Was ist ein Paket ?

Ein Paket ist eine Datei, die meistens foo.pkg.tar.gz genannt ist.

In fact, it is no more than a gzipped tar archive which contains:

• The files to install

• .PKGINFO : contains all the metadata needed by pacman to deal with packages, dependencies, etc.

• .FILELIST : lists all the files of the archive. It's used in order to uninstall the software or to check for file conflicts.

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

What is a PKGBUILD and what does it contain?

As explained before, the PKGBUILD file contains metadata about a package. It is a simple plain text file. Here is an example:

# $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
}

So let's explain each field :

• # text : comments
• # $Id: PKGBUILD,v ... : the cvs-tag for this pkg (from the archlinux-cvs system created)
• # Maintainer : the maintainer responsible for this pkg in the official Repositories
• # Contributor : the person who wrote the first PKGBUILD for this package
• pkgname : the name of the package
• pkgver : the version of the package
• 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 : a brief description of the package. This is what you see when you browse the package database
• arch : shows on what architectures it is known to build and work - see Arch64_FAQ for porting details
• url : the homepage of the software (which appears when you click on a package on the package database)
• 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
• provides : this is used if the package provides another package, for example, kernel-scsi provides kernel
• depends : this lists the run-time dependencies of the package (what it needs to work)
• makedepends : dependencies needed to build the package but which are not needed once the package is built
• conflicts : these packages cannot be installed at the same time. Here, foo conflicts with yafoo (yet another foo). They cannot be installed at the same time.
• replaces : the new package replaces the old one. Here, mffoo (my first foo) is no more supported and being replaced with foo
• backup : which files to backup (as file.pacsave) when the package is removed
• install : specifies a special install script that is to be included in the package (it has to be in the same directory as PKGBUILD)
• 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 pkgname and pkgver in order to avoid changing the source each time the version changes.
• md5sums : md5sums of the source to check their integrity

So now, let's explain the function :

• build : all the actions needed to build the package (it will be explained with more attention later in this document)

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.

There are also install files. This PKGBUILD specifies 'foo.install' as the package's install file. Here is an example install file:

post_install() {
/bin/true
}

post_upgrade() {
/bin/true
}

pre_remove() {
/bin/true
}

op=$1
shift

$op "$@"

Here are the function explainations :

• post_install : this script is run right after files are installed, it takes one argument :
  • the package version
• post_upgrade : this script is run after all files have been upgraded, it takes two arguments :
  • 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.

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 :

  tar -xzf foo-0.99.tar.gz
  tar -xjf foo-0.99.tar.bz2

• enter the directory

cd foo-0.99

• configure the package : generally, there is a little script called configure 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 :

./configure [[option]]

You should first try the help to better understand how it works :

./configure --help

• compile the sources :

make

• install

make install

However, you should always read the INSTALL file to know how the package should be built and install ! Not all packages use the configure; make; make install system!

So let's take a look at a "standard" build function :

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

What we do is :

• enter the directory where sources were uncompressed :

cd $startdir/src/$pkgname-$pkgver

But if you try to build your package, be carefull that this is the right directory : sometimes the uncompressed directory might be named differently :

tar -xzf foo-0.99.tar.gz

and a ls might return :

  .
  ..
  foo-0.99.tar.gz
  foo/

and not :

  .
  ..
  foo-0.99.tar.gz
  foo-0.99/

• configure the package, and tell it to install in the /usr directory :

  ./configure --prefix=/usr

• compile

  make || return 1

• install the software but not in /usr, in $startdir/pkg/usr so that pacman has control of the files.

  make prefix=$startdir/pkg/usr install

What we want to do is build the package not to install it, so instead of installing to the standard place (/usr), we tell make to put all files in our special directory : $startdir/pkg/usr. Thus, makepkg can look and see which files the package installs, and then compress them into the Arch package.

NOTE: It is sometimes the case where prefix is not used in the Makefile; often DESTDIR is used instead. If the package is built with autoconf/automake, use DESTDIR, this is what is documented in the manuals. Check if the generated filelist is a lot shorter than it should be, and if so, try building with make DESTDIR=$startdir/pkg install. If that does not work, you'll have to look further into the install commands that are executed by "make <...> install=".

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

• [2]
• chapter/make9.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