pacman/doc/PKGBUILD.8

.TH PKGBUILD 8 "June 13, 2006" "Archlinux Developer Manual" ""
.SH NAME
PKGBUILD \- Archlinux package builder descriptor
.SH DESCRIPTION
This manual page is meant to describe general rules about PKGBUILDs. If
you're interested in the package builder \fBmakepkg\fP itself, then see its
manual page, not this one.

.TP
.TP
.SH PKGBUILD Example:
.RS
.nf
# Last Modified: Sun, 19 Jun 2005 15:24:32 +0000
# Compiling Time: 0.17 SBU
# Maintainer: Name <email@addr.ess>

pkgname=dvdauthor
pkgver=0.6.11
pkgrel=3
pkgdesc="Will generate a DVD movie from a valid mpeg2 stream"
depends=('imagemagick' 'libdvdread')
Finclude sourceforge
groups=('xapps')
archs=('i686' 'x86_64')
sha1sums=('a99ea7ef6e50646b77ad47a015127925053d34ea')

# optimization OK
.fi
.RE

As you can see, the setup is fairly simple. The first line tracks the time of
the last update, this is automatically updated after a successful build.

The next line defines its build time. Of course, it depends on your hardware,
so we use SBUs instead of minutes as a unit.

SBU is the Static Binutils Unit, which means the time "repoman merge binutils"
takes on your machine. By default makepkg will print out how many seconds the
build took. After you built binutils, you should update your /etc/makepkg.conf:

SBU="257"

The line above means compiling binutils on your machine took 257 seconds.
Starting from this point, makepkg will print out SBUs instead of seconds after
successful builds, and this SBU value will be equal on anyone's machine.

If you wish to maintain the package, write your name or nick and e-mail
address to the third line. If you don't plan to maintain the package just wrote
the PKGBUILD, then write Contributor instead of Maintainer, and then someone
can take it and will add his/her line later. Other lines like "Modified by" are
not allowed. Use the darcs patch comments to mention others if you wish.

pkgname defines the package name. It should not contain any uppercase letters.
The package version defines the upstream version, while the package release
tracks the Archlinux-specific changes. pkgrel should be an integer, pkgrels
like 5wanda1 are reserved for security updates. There the rule is the
following: If the original package's pkgrel was 4, then increment it once when
you add a security patch, but then use 5wanda1, 5wanda2 and so on. This way
the user can easily upgrade to pkgrel=5 which is in -current.

pkgdesc is a short one-line description for the package. Usually taken from
the project's homepage or manpage. Try to keep the lenght under 80 chars.

depends() is a bash array which defines the dependencies of the package.
depends() means the other package is required for building and using the
current one. If the dependency is runtime-only, then use rodepends(), if
buildtime-only then use makedepends().

The next line is a special Finclude commands which allows you to inherit
any directive from a PKGBUILD scheme. They can be found in the FST,
under /source/include. The "util" scheme always included, since its
provided functions are used by almost every PKGBUILD. Look at the
/source/include/sourceforge.sh, it provides the url, up2date and source()
directives, so we don't have to specify them here. After the Finclude you
can overwrite the inherited directives, for example define a custom up2date
if the inherited one is not sutable for you.

The groups() array's first element can't be omitted, and it should be a valid
"first group". This means it should be in a foo or foo-extra format, where foo
or foo-extra is a dir under /source in the FST.

The archs() array defines for which architectures the given package is
available. If it's not available, it means that gensync will skip it when
generating package databases. If you are not able to provide a binary package
for a given arch, don't include that in archs()! For example, no matter if
the package could be compiled in x86_64, if you haven't compiled it yourself,
don't include it. If you're sure it won't be available on a given arch (for
example it's written in x86 asm), then use !arch, for example !x86_64.

The sha1sums() array can be generated with the makepkg -g command. Its purpose
is to prevent compiling from wrong sources, especially when the build is
automatic. Where it is available you can use signatures(), its goal is that
you don't have to update it manually every time.

The last line will be added automatically to the end of the PKGBUILD if the
build() function used your $CFLAGS or $CXXFLAGS. This is handy if you want to
cross-compile on a faster machine for a slower architecture. Until the package
doesn't use our $CFLAGS we can't cross-compile it, so please try to avoid
creating "unoptimized" packages. If the package doesn't contain any
architecture-dependent file, then you can add this line manually as makepkg
will not detect this.

Finally we define a build() function that will build the package. If you don't
want to do anything special, probably you don't have to specify anything, as
the default build() (inherited from util.sh) will fit your needs. Even if you
define a custom build(), probably you can re-use parts of the default build().
For the list of special functions provided by util.sh and others refer to
the /source/include dir. Again, util.sh is included automatically, but you
have to Finclude the others before using them!

Once the package is successfully installed into the package root, \fImakepkg\fP
will prepare some documentation. It will
then strip debugging info from libraries and binaries and generate a meta-info
file.  Finally, it will compress everything into a .fpm file and leave it
in the directory you ran \fBmakepkg\fP from.

At this point you should have a package file in the current directory, named
something like name-version-release-arch.fpm.  Done!

.SH Install/Upgrade/Remove Scripting
Pacman has the ability to store and execute a package-specific script when it
installs, removes, or upgrades a package.  This allows a package to "configure
itself" after installation and do the opposite right before it is removed.

The exact time the script is run varies with each operation:
.TP
.B pre_install
script is run right before files are extracted.

.TP
.B post_install
script is run right after files are extracted.

.TP
.B pre_upgrade
script is run right before files are extracted.

.TP
.B post_upgrade
script is run after files are extracted.

.TP
.B pre_remove
script is run right before files are removed.

.TP
.B post_remove
script is run right after files are removed.

.RE
To use this feature, just create a file (eg, pkgname.install) and put it in
the same directory as the PKGBUILD script.  Then use the \fIinstall\fP directive:
.RS
.nf
install=pkgname.install
.fi
.RE

The install script does not need to be specified in the \fIsource\fP array.
If you omit the install directive then makepkg will check for the
$pkgname.install install and will use it if it's present.

You can find a scriptlet skeleton in the /docs/tech/skel/ directory, use it
when creating new packages.

The scriptlet messages are parsed, a simple example tells you everything:
.nf
post_upgrade()
{
	echo "START this will be good"
	echo "DONE 0"
	echo "START this will fail"
	echo "DONE 1"
	echo "old message"
}
.fi

.SH PKGBUILD Directives
.TP
.B pkgname
The name of the package.  This has be a unix-friendly name as it will be
used in the package filename.

.TP
.B pkgver
This is the version of the software as released from the author (eg, 2.7.1).

.TP
.B pkgrel
This is the release number specific to Archlinux Linux packages.

.TP
.B pkgdesc
This should be a brief description of the package and its functionality.

.TP
.B pkgdesc_localized
Array of the localized package descriptions.

The format is the following:
pkgdesc_localized=('xx_YY foo' 'xx_YY bar')

.TP
.B url
This field contains an optional URL that is associated with the piece of software
being packaged.  This is typically the project's website.

.TP
.B license
Sets the license type (eg, "GPL", "BSD", "NON-FREE").  (\fBNote\fP: This
option is still in development and may change in the future)

.TP
.B install
Specifies a special install script that is to be included in the package.
This file should reside in the same directory as the PKGBUILD, and will be
copied into the package by makepkg.  It does not need to be included in the
\fIsource\fP array.  (eg, install=modutils.install)

.TP
.B up2date
This directive should contain a command that prints the current upstream stable
version of the project. This way we can check for newer version without visiting
manually the project's website (see above).

.TP
.B source \fI(array)\fP 
The \fIsource\fP line is an array of source files required to build the
package.  Source files must reside in the same directory as the PKGBUILD
file, unless they have a fully-qualified URL.  Then if the source file
does not already exist in /var/cache/pacman/src, the file is downloaded
by wget.

.TP
.B md5sums \fI(array)\fP
If this field is present, it should contain an MD5 hash for every source file
specified in the \fIsource\fP array (in the same order).  makepkg will use
this to verify source file integrity during subsequent builds.  To easily
generate md5sums, first build using the PKGBUILD then run
\fBmakepkg -G >>PKGBUILD\fP.  Then you can edit the PKGBUILD and move the
\fImd5sums\fP line from the bottom to an appropriate location.

.TP
.B sha1sums \fI(array)\fP
If this field is present, it should contain an SHA1 hash for every source file
specified in the \fIsource\fP array (in the same order).  makepkg will use
this to verify source file integrity during subsequent builds.  To easily
generate sha1sums, first build using the PKGBUILD then run
\fBmakepkg -g >>PKGBUILD\fP.  Then you can edit the PKGBUILD and move the
\fIsha1sums\fP line from the bottom to an appropriate location.

.TP
.B signatures \fI(array)\fP
If this field is present, it should contain an array of gpg signatures required
to validate the source files. Where there is no signature available just leave
it empty, like:

signatures=(${source[0]}.asc '')

.TP
.B groups \fI(array)\fP
This is an array of symbolic names that represent groups of packages, allowing
you to install multiple packages by requesting a single target.  For example,
one could install all KDE packages by installing the 'kde' group.

.TP
.B archs \fI(array)\fP
This array defines on which architectures the given package is avalibable.
If it's not available, that will mean that gensync will skip it when generating
package databases.

.TP
.B backup \fI(array)\fP 
A space-delimited array of filenames (without a preceding slash). The
\fIbackup\fP line will be propagated to the package meta-info file for
pacman.  This will designate all files listed there to be backed up if this
package is ever removed from a system.  See \fBHANDLING CONFIG FILES\fP in
the \fIpacman\fP manpage for more information.

.TP
.B depends \fI(array)\fP 
An array of packages that this package depends on to build and run.  Packages
in this list should be surrounded with single quotes and contain at least the
package name.  They can also include a version requirement of the form
\fBname<>version\fP, where <> is one of these three comparisons: \fB>=\fP
(greater than equal to), \fB<=\fP (less than or equal to), or \fB=\fP (equal to).
See the PKGBUILD example above for an example of the \fIdepends\fP directive.

.TP
.B makedepends \fI(array)\fP
An array of packages that this package depends on to build (ie, not required
to run).  Packages in this list should follow the same format as \fIdepends\fP.

.TP
.B rodepends \fI(array)\fP
An array of packages that this package depends on to run (ie, not required to
build). Generally \fIrodepends\fP should be avoided in favour of \fIdepends\fP
except where this will create circular dependency chains. (For example building
logrotate doesn't requires to have dcron installed.) Packages in this list
should follow the same format as \fIdepends\fP.

.TP
.B conflicts \fI(array)\fP 
An array of packages that will conflict with this package (ie, they cannot both
be installed at the same time).  This directive follows the same format as
\fIdepends\fP except you cannot specify versions here, only package names.

.TP
.B provides \fI(array)\fP 
An array of "virtual provisions" that this package provides.  This allows a package
to provide dependency names other than it's own package name.  For example, the
kernel-scsi and kernel-ide packages can each provide 'kernel' which allows packages
to simply depend on 'kernel' rather than "kernel-scsi OR kernel-ide OR ..."

.TP
.B replaces \fI(array)\fP 
This is an array of packages that this package should replace, and can be used to handle
renamed/combined packages.  For example, if the kernel package gets renamed
to kernel-ide, then subsequent 'pacman -Syu' calls will not pick up the upgrade, due
to the differing package names.  \fIreplaces\fP handles this.

.TP
.B options \fI(array)\fP
This is an array of various boolean options. The possible values are:
.nf
nodocs     Don't add any documentation automatically (ie. when there'll be
           a separate documentation subpackage).
nostrip    Don't strip binaries/libraries.
force      This is used to force the package to be upgraded by --sysupgrade,
           even if its an older version.
nobuild    If this directive set, gensync will ignore this package, so users
           must build  these packages on their machines, they will not be able
           to install them with pacman -S. Useful for closed-source, but
           freeware programs.
nofakeroot Don't drop privileges after chrooting. Required by some broken
           packages.
scriptlet Don't skip executing scriptlets even if we're in chroot.
.fi

.SH  What is the process of chrooted build ?

First, what is chroot? We currently use fakeroot to prevent build() from
modifying the host system, and we use a prefix or DESTDIR directive to install
everything to a directory and not under to the host system. This is good, but
not enough.

This system lacks of the ability to control the list of installed packages
during the build on the system of a packager, the given compiled package maybe
linked itself to an extra installed library. This way we can't really control
the list of real dependencies. For example if libquicktime is installed from
source on my system, then mplayer or any other program can link itself to that,
and so that depends() will be incorrect. Or if I have the closed source binary
NVidia drivers installed, some programs link tho NVidia's libraries.

Of course there is a sollution to avoid this, to use a real chroot instead of a
simple fakeroot. What is this means? The followings:

When starting the build, a core chroot system is installed under /var/chroot.
(Of course you can change this value under /etc/makepkg.conf.) The core system
contains ~60 packages which are must installed to build any package in
a chrooted environment. These packages (for example gcc, kernel-headers, make)
should not be mentioned in makedepends(). 'pacman -Sg core chroot-core
devel-core' should show you the actial list. (We try to change this list rarely
of course.)

When you start building with makepkg -R, pacman will install these packages to
/var/chroot if necessary. This will produce a fully "clean" Archlinux system,
that consits of base packages only. This /var/chroot is fully separated from
the host system so that this will solve the problems mentioned above.
(Linking to a library installed from source, etc.)

Here comes the fun part. The packages listed in depends() and makedepends() are
installed to this clean (/var/chroot) system. From this point, this chroot is
capable to build the specified package in it without any unnecessary package
installed, fully separated from the host system.

After this the chroot should be cleaned up which means the removal of the
installed depends() and makedepends(). This ensures us not to build from
scratch the core chroot.

This way we can prevent lots of dependency problems and it is even possible to
build packages for a different Archlinux version. This is quite efficent when
building security updates or fixing critical bugs in the -stable tree.

If the build is failed, the working directory will not be deleted, you can find
it under /var/chroot/var/tmp/fst. Later if you want to clean your chroot
(delete the working directory and remove unnecessary packages) you can use 'makepkg -CR'.

To activate building in a chroot, you should run makepkg as root at least with
the -R option.

.SH Package splitting

Package splitting means moving out a list of specifed files to subpackages (like
libmysql out of mysql) and then defining the properties of subpackages.

NOTE: if you create several subpackages, maintaining those packages will
require more and more time. Thus, unnecessary splits aren't welcome.
Especially, if you split out a library, then don't move the headers to the
package just to speed up building with a few seconds!

The \fBsubpkgs()\fP array is to define the pkgnames of the subpackages. From
now all the directives has their subfoo equivalent:
.nf
pkgname -> subpkgs()
pkgdesc -> subdescs()
pkgdesc_localized -> subdescs_localized()
license() -> sublicense()
replaces() -> subreplaces()
groups() -> subgroups()
depends() -> subdepends()
rodepends() -> subrodepends()
removes() -> subremoves()
conflicts() -> subconflicts()
provides() -> subprovides()
backup() -> subbackup()
install -> subinstall()
options -> suboptions()
archs -> subarchs()
.fi

Also note that bash does not support two-dimensional arrays, so when defining the
array of arrays, then quotes are the major separators and spaces are the minor ones.

Simple example:
.nf
Add the followings to your bottom of your PKGBUILD
subpkgs=('foo' 'bar')
subdescs=('desc of foo' 'desc of bar')
subdepends=('foodep1 foodep2' 'bardep1 bardep2')
subgroups=('apps' 'apps')
subarchs=('i686 x86_64' 'i686 x86_64')
.fi

You may define conflicts, replaces and other directives for your subpackages, but
the requirement is only to define these 5 ones.

The second part is to move some files to the - just defined - subpackages. You
should use the Fsplit command for this at the end of your build() function. You
can read more about Fsplit in the fwmakepkg documentation, but here is a short
example:
.nf

Fsplit subpkgname usr/share/

.fi
This will move the /usr/share dir of the package to the "subpkgname" subpackage.

NOTE: never use a trailing slash when defining file patterns, especially if you
use wildcards in it!

.SH "SEE ALSO"
.BR makepkg (8),
.BR pacman (8)
.SH AUTHOR
.nf
Judd Vinet <jvinet@zeroflux.org>
and the Frugalware developers <frugalware-devel@frugalware.org>
.fi