Arch Build System (Dansk)

From ArchWiki
Revision as of 18:53, 12 December 2007 by Jan-portugal (Talk | contribs)

Jump to: navigation, search

C ategory:Dansk Ca tegory:Package management (Dansk)

Summary help replacing me
Forklarer om byggesystemet i Arch Linux
Tilgængelig på følgende sprog

Template:I18n entry Template:I18n entry Template:I18n entry Template:I18n entry Template:I18n entry

Relaterede artikler (Engelsk)
AUR_Trusted_User_Guidelines
AUR
AUR Q & A
Aurbuild
Andre artikler på dansk
Main_Page_(Dansk)

Hvad er ABS?

ABS er en forkortelse af Arch Build System - eller på dansk Archs byggesystem. Det er et 'ports'-lignende system til at bygge software fra kilden.

Hvad er et 'ports'-lignende system?

'Ports' er et system, anvendt af FreeBSD, der lader kilde-pakker blive downloadet, udpakket, tilrettet, kompileret og installeret. En 'port' er blot en lille mappe på brugerens computer med et navn, der svarer til det software der installeres. Denne mappe indeholder nogle få filer med instruktioner for download og installation af en pakke fra en kilde, typisk ved at navigere til mappen - eller porten - og udføre kommandoerne make og make install. Systemet vil så downloade, kompilere og installere det ønskede software. En typisk bruger af BSD-porte vil downloade hele port-hierarkiet, der blot er et mappetræ med mange undermapper - eller porte, der hver svarer til det respektive i9nstallerbare software.

ABS er et lignende koncept.

ABS laves ud fra et mappetræ, (ABS-træet), der findes under /var/abs, som indeholder mange undermapper. Hver mappe i sin kategori og alle navngivet af deres respective byggebare pakke.
Du kan kalde enhver undermappe - med navn efter pakken - for et ABS. Det samme som man vilde kalde en 'port'. Disse ABS-er - eller undermapper indeholder hverken software-pakken eller kilden, men nærmere en PKGBUILD-fil (og somme tider andre filer). En PKGBUILD er en simpel tekstfil, der indeholder instruktioner til kompilering og pakning, så vel som en URL til det tar-arkiv, som skal downloades. Den vigtigste komponent i ABS er PKGBUILD.

Hurtig gennemgang

Kør kommandoen abs som 'root' for at oprette ABS-træet. Hvis du f.eks. vil bygge editoren Nano fra kilden, skal du kopiere filen /var/abs/core/base/nano til en byggemappe. Gå ind i byggemappen og kør en makepkg. Så enkelt er det.
'Makepkg' vil forsøge at læse og eksekvere de instruktioner, der findes i PKGBUILD-filen. Tar-arkivet fra kilden downloades, udpakkes, kompileres og klemmes ind i en pakke med fil-endelsen .pkg.tar.gz, som det instrueres i filen PKGBUILD.
Installation er så nemt, som at køre en pacman -U nano.pkg.tar.gz, eller lav pakken og installér den rent med Pacman. Alt med kun én kommando.
Fjernelse af pakken håndteres også af Pacman.

The PKGBUILD and other files may, of course, be customized to suit your needs, and you may choose to use the ABS makepkg function to make your own custom packages from sources outside the ABS tree itself. (See the prototype PKGBUILD and install files under /var/abs/core/)


With the ABS Tree in place, an Arch user has all available Arch packages at their fingertips, to compile from source. ABS tools may also be used for building custom packages from source for your system, and/or shared with the community in conjunction with the AUR.

As always, man makepkg for more specific information.

TODO: brief makeworld explanation

makeworld has no man page, so do makeworld --help.

Why would I want to use ABS?

The Arch Build System (ABS for short) is used to

  • Make new packages from source, of software for which no packages are yet available (See The Arch package making HOW-TO - with guidelines)
  • Customize existing packages to fit your needs (enabling or disabling options)
  • Rebuild your entire system using your compiler flags, "a la FreeBSD"
  • Get kernel modules working with your custom kernel.

ABS is not necessary to use Arch Linux, but it is useful.

This how-to tries to give you an overview of ABS and Arch packages; it's not a complete reference guide! If you want more, you should try to read the man pages.

Install Packages

To use abs, you first need to install cvsup and wget; this can be done simply by:

pacman -Sy cvsup wget

As an alternative to cvsup, you can also use csup, a faster version of cvsup written in C:

pacman -Sy csup

/etc/abs/abs.conf

edit /etc/abs/abs.conf to include your desired repositories:

nano /etc/abs/abs.conf

Remove the ! in front of the appropriate repos, e.g.:

SUPFILES=(core extra !unstable community !testing)

Create the ABS tree

As root, do:

abs

Your ABS tree is now created under /var/abs. Note the appropriate branches of the ABS tree now exist and correspond to the ones you specified in /etc/abs/abs.conf.

The abs command should also be used to periodically sync and update your ABS Tree.

The ABS tree

When you run abs for the first time, it synchronizes the ABS tree with the Arch server using the cvs system. So what exactly is the ABS tree? It is located under /var/abs and looks like this:

|-
| -- core/
|-
|     ||-- autoconf/
|-
|     ||-- automake/
|-
|     ||-- ...
|-
| -- devel/
|-
| -- ...
|-
| -- extra/
|-
|      || -- daemons/
|-
|      ||      || -- acpid/
|-
|      ||      ||      || -- PKGBUILD
...    ...    ...    ...

So the ABS tree has exactly the same structure as the package database:

  • first-level directory represents categories
  • second-level directories represents the ABS themselves, whose names actually correspond to the packages you want to build
  • PKGBUILD files contain all information needed concerning the package
  • Further, an ABS directory can contain patches and/or other files needed for building the package.

It is important to understand that the actual source code for the package is not present in the ABS directory. Instead, the PKGBUILD file contains a URL from which ABS will automatically download from.

/var/abs/local/

Within the ABS Tree, 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. Copy the ABS from the tree (var/abs/branch/category/pkgname) to the build directory, (/var/abs/local/).

Create your /var/abs/local/ build directory:

mkdir /var/abs/local

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 is compressed during the transfer.

Now that you know what the ABS tree is, how can we use it ?

The build function, traditional method

If you're not familiar with compiling from source, you should know that most packages (but not all) can be built from source in this traditional way:

  • Download source tarball from remote server, using web browser, ftp, wget or alternate method.
  • 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 that is used to configure the package (add or remove support for things, choose the install destination, etc.) 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

If a --prefix option is not passed to the script, most scripts will use /usr/local as the install path, but others will use /usr. For the sake of consistency, it is generally advised to pass the --prefix=/usr/local option. It is good practice to install personal programs in /usr/local, and to have the ones being managed by the distro, in /usr. This ensures personal program versions can coexist with those being managed by the distro's package manager- in Arch's case, pacman.

./configure --prefix=/usr/local
  • compile the sources:
make
  • install
make install
  • Uninstalling would be accomplished by entering the source directory and running:
make uninstall

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

The build function, the ABS way

ABS is an elegant tool which allows for powerful assistance and customization for the build process, and creates a package file for installation. The ABS method involves copying an ABS from the Tree to a build directory, and doing makepkg. In our example, we will build the slim display manager package.

  • 1. Copy the slim ABS from the Tree to a build directory.
cp -r /var/abs/extra/x11/slim /var/abs/local
  • 2. Navigate to the build directory
cd /var/abs/local/slim
  • 3. Do makepkg, which will automatically download the source tarball, unpack, compile, and create foo.pkg.tar.gz The -i option invokes pacman to automatically install the resulting slim.pkg.tar.gz package file
makepkg -i

That's it. You have just built slim from source and cleanly installed it to your system with pacman. Package removal is also handled by pacman- (pacman -R slim)

Alternatively, you may do makepkg without the -i option, and manually install with pacman by doing:

 pacman -U foo.pkg.tar.gz

Useful Options

Some useful makepkg options, from the makepkg man page:

-c, --clean
             Clean up leftover work files and directories after a successful build.
-f, --force
             makepkg  will  not build a package if a built package already exists in the PKGDEST (set in makepkg.conf) directory, 
             which may default to the current directory. This allows the built package to be overwritten.
-i, --install
             Install or upgrade the package after a successful build using pacman.
-s, --syncdeps
             Install  missing dependencies using pacman. When missing build-time or run-time dependencies are found, pacman will 
             try to resolve them. If successful, the missing packages will be downloaded and installed.

Therefore, makepkg -csi will grab all dependencies (if any), install (with pacman), and clean up all leftover work files from the build directory.

Again, consult man makepkg for more.

TODO: Explain makeworld function for rebuilding whole system, etc.

What is a package file?

Remember, ABS automatically downloads the source code for the particular software you are compiling. It then unpacks, compiles the sources and squeezes everything into an installable package. Typically, the resulting package file is a file called foo.pkg.tar.gz.

In fact, it is no more than a gzipped tar archive or 'tarball' 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 present only if specified in the PKGBUILD.)

Since pacman manages tar.gz packages, foo.pkg.tar.gz can now easily be installed/removed.

What is a PKGBUILD and what does it contain?

As explained before, the PKGBUILD file contains metadata about a package. It is a 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, i.e. '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
}

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)
  • license: the license under which the software is distributed
  • groups: this is used to group packages; when you try to install kde, for example, it installs all packages that belong 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 longer supported and is being replaced with foo
  • backup: which files to back up (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 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 in more detail 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 explanations:

  • 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.



Build function explained

So let's take a look at an ABS build function as dictated by the PKGBUILD example from above. Note the build section:

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

What is happening:

  • enter the directory where sources were uncompressed:
cd $startdir/src/$pkgname-$pkgver
  • configure the package, and tell it to install in the /usr directory:
  ./configure --prefix=/usr
  • compile
  make || return 1
  • install the software not in /usr, but instead in $startdir/pkg/usr so that pacman has control of the files.
  make prefix=$startdir/pkg/usr install

What we want to do is to 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=".

First use of ABS: customizing a package

This situation can arise more often than you might think: official packages are compiled having chosen 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 the foo package located. You can do this by:
    • searching for foo at [1]
    • using the find command:
  find /var/abs -name "foo"
    • using 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 ABS to /var/abs/local/foo
  cp -r /var/abs/extra/multimedia/foo/ /var/abs/local
  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 -c

(The -c option cleans up leftover files from the build.)

  • install the new package using one of the following commands (-A for install [deprecated method], -U to upgrade or install 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.

#
# /etc/makepkg.conf
#

#########################################################################
# SOURCE ACQUISITION
#########################################################################
#
#-- The FTP/HTTP download utility that makepkg should use to acquire sources
FTPAGENT="/usr/bin/wget --continue --passive-ftp --tries=3 --waitretry=3 --no-check-certificate"
#FTPAGENT="/usr/bin/snarf"
#FTPAGENT="/usr/bin/lftpget -c"

#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="i686"
CHOST="i686-pc-linux-gnu"

#-- Exclusive: will only run on i686
# -mtune builds exclusively for an architecture
# -mcpu optimizes for an architecture, but builds for the whole processor family
CFLAGS="-march=i686 -O2 -pipe"
CXXFLAGS="-march=i686 -O2 -pipe"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j2"

#########################################################################
# BUILD ENVIRONMENT
#########################################################################
#
# Defaults: BUILDENV=(!fakeroot !distcc color !ccache)
#
#-- fakeroot: Allow building packages as a non-root user
#-- distcc:   Use the Distributed C/C++/ObjC compiler
#-- color:    Colorize output messages
#-- ccache:   Use ccache to cache compilation
#
BUILDENV=(fakeroot !distcc color !ccache)
#
#-- If using DistCC, your MAKEFLAGS will also need modification. In addition,
#-- specify a space-delimited list of hosts running in the DistCC cluster.
#DISTCC_HOSTS=""

#########################################################################
# GLOBAL PACKAGE OPTIONS
#   These are default values for the options=() settings
#########################################################################
#
# Default: OPTIONS=(strip !docs !libtool emptydirs)
#
#-- strip:     Strip symbols from binaries/libraries
#-- docs:      Save doc and info directories
#-- libtool:   Leave libtool (.la) files in packages
#-- emptydirs: Leave empty directories in packages
#
OPTIONS=(strip !docs libtool emptydirs)

#-- File integrity checks to use. Valid: md5, sha1, sha256, sha384, sha512
INTEGRITY_CHECK=(md5)
#-- Info and doc directories to remove (if option set correctly above)
DOC_DIRS=(usr/{,share/}{info,doc,gtk-doc} opt/gnome/{,share/}{info,doc,gtk-doc})

#########################################################################
# PACKAGE OUTPUT
#########################################################################
#
# Default: put built package and cached source in build directory
#
#-- Destination: specify a fixed directory where all packages will be placed
PKGDEST=/home/packages
#-- Source cache: specify a fixed directory where source files will be cached
SRCDEST=/home/sources
#-- Packager: name/email of the person or organization building packages
PACKAGER="John Doe <john@doe.com>"

# vim: set ft=sh ts=2 sw=2 et:

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

More ABS info