Difference between revisions of "Arch Build System (Dansk)"

From ArchWiki
Jump to: navigation, search
Line 42: Line 42:
 
''makeworld'' har ingen 'man'-side, så benyt ''makeworld --help''.
 
''makeworld'' har ingen 'man'-side, så benyt ''makeworld --help''.
  
==== Why would I want to use ABS? ====
+
====Hvorfor skulle jeg bruge ABS?====
The Arch Build System (ABS for short) is used to
+
'''A'''rch '''B'''ygge'''S'''ystem (ABS) anvendes til:
 +
* At lave nye pakker fra kilde af software, der endnu ikke er tilgængelig. (Se [[The Arch package making HOW-TO - with guidelines|hvordan du laver pakker til Arch Linux]])
 +
* Tilpas eksisterende pakker, så de passer til dit behov (aktivere eller deaktivere valgmuligheder)
 +
* Genopbyg hele dit system med dine kompileringsflag (a la FreeBSD)
 +
* Få kernemoduler til at virke med din brugertilpassede kerne.
  
* Make new packages from source, of software for which no packages are yet available (See [[The Arch package making HOW-TO - with guidelines]])
+
ABS er ikke nødvendig for at bruge Arch Linux - men det er nyttigt.
* 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.
+
Denne vejledning forsøger at give dig et overblik over ABS og Arch Linux-pakker. Det er ikke en komplet reference-guide!<br>Hvis du vil vide mere, skulle du prøve at kigge på ''man''-siderne.
  
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ér pakker====
  
==== Install Packages ====
+
For at benytte ABS skal du først installere '''cvsup''' og '''wget'''. Dette gøres med
 +
pacman -Sy cvsup wget
  
To use abs, you first need to install '''cvsup''' and '''wget'''; this can be done simply by:
+
Som et alternativ til '''cvsup''' kan du benytte '''csup''' - en hurtigere version skrevet i C:
 +
pacman -Sy csup
  
<pre>
+
====/etc/abs/abs.conf====
pacman -Sy cvsup wget</pre>
+
Redigér /etc/abs/abs.conf til at inkludere dine software-kilder:
 
+
As an alternative to '''cvsup''', you can also use '''csup''', a faster version of cvsup written in C:
+
 
+
<pre>
+
pacman -Sy csup</pre>
+
 
+
==== /etc/abs/abs.conf ====
+
edit /etc/abs/abs.conf to include your desired repositories:
+
 
  nano /etc/abs/abs.conf
 
  nano /etc/abs/abs.conf
Remove the ! in front of the appropriate repos, e.g.:
+
Fjern udråbstegnet '!' foran de passende software-kilder som f.eks.:
 
  SUPFILES=(core extra !unstable community !testing)
 
  SUPFILES=(core extra !unstable community !testing)
==== Create the ABS tree ====
+
====Opret ABS-træet====
As root, do:
+
Som 'root' køres:
 
  abs
 
  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.  
+
Dit ABS-træ er nu oprettet under /var/abs. Bemærk de passende grene på ABS-træet nu eksisterer og svarer til dem du specificerede i /etc/abs/abs.conf.  
  
''The abs command should also be used to periodically sync and update your ABS Tree.''
+
''Kommandoen '''abs''' bør også benyttes til regelmæssigt at synkronisere og opdatere dit ABS-træ.''
  
==== The ABS tree ====
+
====ABS-træet====
  
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:
+
Når du kører '''abs''' for første gang, synkroniseres ABS-træet med Ardh-serveren ved hjælp af 'cvs'-systemet. Hvad er så ABS-træet helt specifikt? Det findes under /var/abs, og ser såledesud:
  
 
<pre>
 
<pre>
Line 106: Line 101:
 
</pre>
 
</pre>
  
So the ABS tree has exactly the same structure as the package database:
+
ABS-træet har altså nøjagtigt den samme struktur som pakkedatabasen:
* first-level directory represents categories
+
* Første mappebane repræsenterer kategorier.
* second-level directories represents the ABS themselves, whose names actually correspond to the packages you want to build
+
* Anden mappebane repræsenterer selve ABS-erne, hvis navne svarer til de pakker du vil bygge.
* PKGBUILD files contain all information needed concerning the package
+
* PKGBUILD-filerne indeholder alt nødvendig information omkring pakken.
* Further, an ABS directory can contain patches and/or other files needed for building the package.  
+
* Endvidere kan en ABS-mappe indeholde rettelser og/eller andre filer, der er nødvendige for at bygge pakken.
''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.
+
''Det er vigtigt at forstå, at selve pakkens kildekode ikke findes i ABS-mappen.'' I stedet for indeholder '''PKGBUILD'''-filen en URL fra hvilken ABS automatisk vil downloade.
 
=====/var/abs/local/=====
 
=====/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/).
+
Inde i ABS-træet er der en speciel mappe - '''local'''. Det er '''din''' mappe. I denne mappe kan du gøre alt, og du bør aldrig ændre noget i resten af ABS-træet. Kopiér en ABS fra træet (var/abs/branch/category/''pakkenavn'') til byggemappen (/var/abs/local/).
  
Create your /var/abs/local/ build directory:
+
Opret din byggemappe /var/abs/local/:
 
  mkdir /var/abs/local
 
  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''.
+
BEMÆRK: Den første download af ABS-træet er den største. Derefter er det kun nødvendigt med mindre opdateringer, så vær ikke bange, hvis du kun har en 56k-tilslutning. Der er kun tale om tekstfiler, som er komprimerede under overførslen.
  
Now that you know what the ABS tree is, how can we use it ?
+
Nu hvor vi ved, hvad et ABS-træ er - hvordan kan vi så bruge det?
  
==== The build function, traditional method ====
+
====Byggefunktionen - traditionel metode====
  
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''':
+
Hvis du ikke kender til at kompilere fra kilde, skal du vide, at de fleste pakker (dog ikke alle) kan bygges fra kilde på denne '''traditionelle måde''':
* Download source tarball from remote server, using web browser, ftp, wget or alternate method.
+
* Download kildens tar-arkiv fra en ekstern server med en web-browser, ftp, wget eller andre metoder.
* uncompress the source file:
+
* Pak kildefilen ud som eks.:
 
+
  <pre>
+
 
   tar -xzf foo-0.99.tar.gz
 
   tar -xzf foo-0.99.tar.gz
   tar -xjf foo-0.99.tar.bz2</pre>
+
   tar -xjf foo-0.99.tar.bz2
 
+
* enter the directory
+
  
 +
* Gå ind i mappen:
 
   <pre>cd foo-0.99</pre>
 
   <pre>cd foo-0.99</pre>
  
* configure the package: generally, there is a little script called <code>configure</code> 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:
+
* konfigurér pakken. Generelt er der et lille script ved navn <code>configure</code> i kildemappen, der benyttes til at konfigurere pakken (tilføje eller fjerne understøttelse for noget, vælge destination for installation osv.). Scriptet tjekker også, om din computer har det nødvendige software for pakken. Det kan køres med:
 +
 
 +
./configure [[valgmulighed]]
 +
 
 +
Du skulle først prøve valgmuligheden 'help', for bedre at forstå, hvordan det virker:
 +
./configure --help
  
  <pre>./configure [[option]]</pre>
+
-------------------------
  
You should first try the help to better understand how it works:
 
  
  <pre>./configure --help</pre>
 
 
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''.
 
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
 
  ./configure --prefix=/usr/local

Revision as of 22:53, 12 December 2007

C ategory:Dansk Ca tegory:Package management (Dansk) Template:Article summary start Template:Article summary text Template:Article summary heading Template:I18n entry Template:I18n entry Template:I18n entry Template:I18n entry Template:I18n entry Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary heading Template:Article summary wiki Template:Article summary end

THE ARTICLE IS BEING TRANSLATET by jan-portugal

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.

Filen PKGBUILD og andre filerkan selvfølgelig tilpasses som du ønsker, og du kan vælge at benytte 'makepkg'-funktionen i ABS til at lave egne brugertilpassede pakker fra kilder udenfor selve ABS-træet.(Se en prototype på en PKGBUILD og installationsfile under /var/abs/core/)


Med ABS-træet på plads har en Arch Linux-bruger, der vil kompilere fra kilde, alle tilgængelige pakker ved hånden. ABS-værktøjerne kan også bruges til at bygge fra kilde til dit system, og/eller dele det med fællesskabet i samspil med Arch linux-brugernes software-kilder AUR.

Som altid kan du se man makepkg for mere specifik information.

TODO: kort forklaring om 'makeworld'

makeworld har ingen 'man'-side, så benyt makeworld --help.

Hvorfor skulle jeg bruge ABS?

Arch ByggeSystem (ABS) anvendes til:

  • At lave nye pakker fra kilde af software, der endnu ikke er tilgængelig. (Se hvordan du laver pakker til Arch Linux)
  • Tilpas eksisterende pakker, så de passer til dit behov (aktivere eller deaktivere valgmuligheder)
  • Genopbyg hele dit system med dine kompileringsflag (a la FreeBSD)
  • Få kernemoduler til at virke med din brugertilpassede kerne.

ABS er ikke nødvendig for at bruge Arch Linux - men det er nyttigt.

Denne vejledning forsøger at give dig et overblik over ABS og Arch Linux-pakker. Det er ikke en komplet reference-guide!
Hvis du vil vide mere, skulle du prøve at kigge på man-siderne.

Installér pakker

For at benytte ABS skal du først installere cvsup og wget. Dette gøres med

pacman -Sy cvsup wget

Som et alternativ til cvsup kan du benytte csup - en hurtigere version skrevet i C:

pacman -Sy csup

/etc/abs/abs.conf

Redigér /etc/abs/abs.conf til at inkludere dine software-kilder:

nano /etc/abs/abs.conf

Fjern udråbstegnet '!' foran de passende software-kilder som f.eks.:

SUPFILES=(core extra !unstable community !testing)

Opret ABS-træet

Som 'root' køres:

abs

Dit ABS-træ er nu oprettet under /var/abs. Bemærk de passende grene på ABS-træet nu eksisterer og svarer til dem du specificerede i /etc/abs/abs.conf.

Kommandoen abs bør også benyttes til regelmæssigt at synkronisere og opdatere dit ABS-træ.

ABS-træet

Når du kører abs for første gang, synkroniseres ABS-træet med Ardh-serveren ved hjælp af 'cvs'-systemet. Hvad er så ABS-træet helt specifikt? Det findes under /var/abs, og ser såledesud:

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

ABS-træet har altså nøjagtigt den samme struktur som pakkedatabasen:

  • Første mappebane repræsenterer kategorier.
  • Anden mappebane repræsenterer selve ABS-erne, hvis navne svarer til de pakker du vil bygge.
  • PKGBUILD-filerne indeholder alt nødvendig information omkring pakken.
  • Endvidere kan en ABS-mappe indeholde rettelser og/eller andre filer, der er nødvendige for at bygge pakken.

Det er vigtigt at forstå, at selve pakkens kildekode ikke findes i ABS-mappen. I stedet for indeholder PKGBUILD-filen en URL fra hvilken ABS automatisk vil downloade.

/var/abs/local/

Inde i ABS-træet er der en speciel mappe - local. Det er din mappe. I denne mappe kan du gøre alt, og du bør aldrig ændre noget i resten af ABS-træet. Kopiér en ABS fra træet (var/abs/branch/category/pakkenavn) til byggemappen (/var/abs/local/).

Opret din byggemappe /var/abs/local/:

mkdir /var/abs/local

BEMÆRK: Den første download af ABS-træet er den største. Derefter er det kun nødvendigt med mindre opdateringer, så vær ikke bange, hvis du kun har en 56k-tilslutning. Der er kun tale om tekstfiler, som er komprimerede under overførslen.

Nu hvor vi ved, hvad et ABS-træ er - hvordan kan vi så bruge det?

Byggefunktionen - traditionel metode

Hvis du ikke kender til at kompilere fra kilde, skal du vide, at de fleste pakker (dog ikke alle) kan bygges fra kilde på denne traditionelle måde:

  • Download kildens tar-arkiv fra en ekstern server med en web-browser, ftp, wget eller andre metoder.
  • Pak kildefilen ud som eks.:
 tar -xzf foo-0.99.tar.gz
 tar -xjf foo-0.99.tar.bz2
  • Gå ind i mappen:
cd foo-0.99
  • konfigurér pakken. Generelt er der et lille script ved navn configure i kildemappen, der benyttes til at konfigurere pakken (tilføje eller fjerne understøttelse for noget, vælge destination for installation osv.). Scriptet tjekker også, om din computer har det nødvendige software for pakken. Det kan køres med:
./configure valgmulighed

Du skulle først prøve valgmuligheden 'help', for bedre at forstå, hvordan det virker:

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