PKGBUILD(5) | Pacman Manual | PKGBUILD(5) |
NAME¶
PKGBUILD - Arch Linux package build description file
SYNOPSIS¶
PKGBUILD
DESCRIPTION¶
This manual page describes general rules about PKGBUILDs. Once a PKGBUILD is written, the actual package is built using makepkg and installed with pacman.
Note
An example PKGBUILD, useful for reference, is located in /usr/share/pacman along with other example files such as an install script. You can copy the provided PKGBUILD.proto file to a new package build directory and make customizations to suit your needs.
OPTIONS AND DIRECTIVES¶
The following is a list of standard options and directives available for use in a PKGBUILD. These are all understood and interpreted by makepkg, and most of them will be directly transferred to the built package. The mandatory fields for a minimally functional PKGBUILD are pkgname, pkgver, pkgrel and arch.
If you need to create any custom variables for use in your build process, it is recommended to prefix their name with an _ (underscore). This will prevent any possible name clashes with internal makepkg variables. For example, to store the base kernel version in a variable, use something similar to $_basekernver.
pkgname (array)
pkgver
The pkgver variable can be automatically updated by providing a pkgver() function in the PKGBUILD that outputs the new package version. This is run after downloading and extracting the sources and running the prepare() function (if present), so it can use those files in determining the new pkgver. This is most useful when used with sources from version control systems (see below).
pkgrel
epoch
pkgdesc
url
license (array)
install
changelog
source (array)
Additional architecture-specific sources can be added by appending an underscore and the architecture name e.g., source_x86_64=(). There must be a corresponding integrity array with checksums, e.g. cksums_x86_64=().
It is also possible to change the name of the downloaded file, which is helpful with weird URLs and for handling multiple source files with the same name. The syntax is: source=('filename::url').
makepkg also supports building developmental versions of packages using sources downloaded from version control systems (VCS). For more information, see Using VCS Sources below.
Files in the source array with extensions .sig, .sign or, .asc are recognized by makepkg as PGP signatures and will be automatically used to verify the integrity of the corresponding source file.
validpgpkeys (array)
Only full fingerprints are accepted. They must be uppercase and must not contain whitespace characters.
noextract (array)
cksums (array)
md5sums, sha1sums, sha224sums, sha256sums, sha384sums, sha512sums, b2sums (arrays)
groups (array)
arch (array)
backup (array)
depends (array)
If the dependency name appears to be a library (ends with .so), makepkg will try to find a binary that depends on the library in the built package and append the version needed by the binary. Appending the version yourself disables automatic detection.
Additional architecture-specific depends can be added by appending an underscore and the architecture name e.g., depends_x86_64=().
makedepends (array)
Additional architecture-specific makedepends can be added by appending an underscore and the architecture name e.g., makedepends_x86_64=().
checkdepends (array)
Additional architecture-specific checkdepends can be added by appending an underscore and the architecture name e.g., checkdepends_x86_64=().
optdepends (array)
optdepends=('python: for library bindings')
Additional architecture-specific optdepends can be added by appending an underscore and the architecture name e.g., optdepends_x86_64=().
conflicts (array)
Additional architecture-specific conflicts can be added by appending an underscore and the architecture name e.g., conflicts_x86_64=().
provides (array)
Versioned provisions are also possible, in the name=version format. For example, dcron can provide cron=2.0 to satisfy the cron>=2.0 dependency of other packages. Provisions involving the > and < operators are invalid as only specific versions of a package may be provided.
If the provision name appears to be a library (ends with .so), makepkg will try to find the library in the built package and append the correct version. Appending the version yourself disables automatic detection.
Additional architecture-specific provides can be added by appending an underscore and the architecture name e.g., provides_x86_64=().
replaces (array)
Sysupgrade is currently the only pacman operation that utilizes this field. A normal sync or upgrade will not use its value.
Additional architecture-specific replaces can be added by appending an underscore and the architecture name e.g., replaces_x86_64=().
options (array)
strip
docs
libtool
staticlibs
emptydirs
zipman
ccache
distcc
buildflags
makeflags
debug
lto
PACKAGING FUNCTIONS¶
In addition to the above directives, PKGBUILDs require a set of functions that provide instructions to build and install the package. As a minimum, the PKGBUILD must contain a package() function which installs all the package’s files into the packaging directory, with optional prepare(), build(), and check() functions being used to create those files from source.
This is directly sourced and executed by makepkg, so anything that Bash or the system has available is available for use here. Be sure any exotic commands used are covered by the makedepends array.
If you create any variables of your own in any of these functions, it is recommended to use the Bash local keyword to scope the variable to inside the function.
package() Function
prepare() Function
build() Function
check() Function
All of the above variables such as $pkgname and $pkgver are available for use in the packaging functions. In addition, makepkg defines the following variables:
srcdir
All of the packaging functions defined above are run starting inside $srcdir
pkgdir
startdir
PACKAGE SPLITTING¶
makepkg supports building multiple packages from a single PKGBUILD. This is achieved by assigning an array of package names to the pkgname directive. Each split package uses a corresponding packaging function with name package_foo(), where foo is the name of the split package.
All options and directives for the split packages default to the global values given in the PKGBUILD. Nevertheless, the following ones can be overridden within each split package’s packaging function: pkgdesc, arch, url, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options, install, and changelog.
Note that makepkg does not consider split package depends when checking if dependencies are installed before package building and with --syncdeps. All packages required to make the package are required to be specified in the global depends and makedepends arrays.
An optional global directive is available when building a split package:
pkgbase
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 perform an opposite action upon removal.
The exact time the script is run varies with each operation, and should be self-explanatory. Note that during an upgrade operation, none of the install or remove functions will be called.
Scripts are passed either one or two “full version strings”, where a full version string is either pkgver-pkgrel or epoch:pkgver-pkgrel, if epoch is non-zero.
pre_install
post_install
pre_upgrade
post_upgrade
pre_remove
post_remove
To use this feature, create a file such as pkgname.install and put it in the same directory as the PKGBUILD script. Then use the install directive:
install=pkgname.install
The install script does not need to be specified in the source array. A template install file is available in /usr/share/pacman as proto.install for reference with all of the available functions defined.
USING VCS SOURCES¶
Building a developmental version of a package using sources from a version control system (VCS) is enabled by specifying the source in the form:
source=('directory::url#fragment?query')
Currently makepkg supports the Bazaar, Git, Subversion, Fossil and Mercurial version control systems. For other version control systems, manual cloning of upstream repositories must be done in the prepare() function.
The source URL is divided into four components:
directory
url
fragment
bzr
fossil
git
hg
svn
query
EXAMPLE¶
The following is an example PKGBUILD for the patch package. For more examples, look through the build files of your distribution’s packages. For those using Arch Linux, consult the Arch Build System (ABS) tree.
# Maintainer: Joe User <joe.user@example.com> pkgname=patch pkgver=2.7.1 pkgrel=1 pkgdesc="A utility to apply patch files to original sources" arch=('i686' 'x86_64') url="https://www.gnu.org/software/patch/patch.html" license=('GPL') groups=('base-devel') depends=('glibc') makedepends=('ed') optdepends=('ed: for "patch -e" functionality') source=("ftp://ftp.gnu.org/gnu/$pkgname/$pkgname-$pkgver.tar.xz"{,.sig}) md5sums=('e9ae5393426d3ad783a300a338c09b72'
'SKIP') build() {
cd "$srcdir/$pkgname-$pkgver"
./configure --prefix=/usr
make } package() {
cd "$srcdir/$pkgname-$pkgver"
make DESTDIR="$pkgdir/" install }
SEE ALSO¶
makepkg(8), pacman(8), makepkg.conf(5)
See the pacman website at https://archlinux.org/pacman/ for current information on pacman and its related tools.
BUGS¶
Bugs? You must be kidding; there are no bugs in this software. But if we happen to be wrong, submit a bug report with as much detail as possible at the Arch Linux Bug Tracker in the Pacman section.
AUTHORS¶
Current maintainers:
Past major contributors:
For additional contributors, use git shortlog -s on the pacman.git repository.
2024-03-27 | Pacman 6.0.2 |