| APKBUILD(5) | File Formats Manual (prm) | APKBUILD(5) |
APKBUILD —
metadata and instructions to build a package
/usr/src/packages/<repo>/<package>/APKBUILD |
An APKBUILD file is used by tools such as
abuild(1) to build a package for eventual installation by
the apk(8) package manager. It defines metadata such as
the name of the package, the version information, the source license, and
contact information for the developer. It additionally contains the commands
needed to build, test, and install the package.
The APKBUILD format is similar to a
typical shell script; you set pre-defined variables and implement
pre-defined functions, and the abuild(1) (or similar)
utility will use them to create the package.
The following variables must be set in all
APKBUILD files:
pkgnameLibraries for scripting languages should have a prefix before the library name describing the language. Such prefixes include lua-, perl-, py-, and rb-. Not all languages use prefixes. For a definitive list, consult the PREFIXES file in the root directory of the repository you are using for packaging.
pkgverAfter the final number (and optional single letter), a suffix may be appended, which must be an underscore (_) followed by one of alpha, beta, pre, rc, cvs, svn, git, hg, or p, optionally followed by another number. If the suffix is alpha, beta, pre, or rc, it is considered to be earlier than the version without a suffix; if the suffix is cvs, svn, git, hg, or p, it is considered to be later than the version without a suffix. All of the following examples are valid versions, in order from lowest to highest:
1.0, 1.1_alpha2, 1.1.3_pre, 1.1.3, 1.1.3_hg, 1.2, 1.2a, 1.2b
pkgrelpkgrel when you
change the contents, dependencies, or metadata of a package. The first
release of a package is always 0.pkgdescpkgdesc must
be 128 characters or less, and should concisely describe what actions the
software or items being packaged will allow the user to perform. For
example, “Fully-featured word processor with spell check and many
plugins” would be a sufficient pkgdesc for
AbiWord.urlurl to an empty string
("").archYou may use "noarch" if the package does not contain any architecture-specific binary files - that is, any files that are compiled for the target only. Such packages may include pure Python packages, shell script packages, and JARs. If you are not sure what this means, using "all" is safe.
licensesourceThe following variables are not required, but may be set in any
APKBUILD file:
checkdependsdependsinstallinstall_ifinstall_if to
$pkgname=$pkgver openrc which means that the
OpenRC subpackage will be automatically installed if the origin package
and OpenRC are both installed on the same computer.ldpathmakedependspkggroupspkgusersprovidesprovides: a provider name, and a provider name
with version.
Specifying a provider name with version such as
foobar=1.2 will cause the package to be an
"alias" of foobar version 1.2. It will be automatically
installed if a user then runs apk add foobar or
similar, and it will conflict with a package named foobar.
Specifying a provider name without a version such as
baz will cause the package to provide a
"virtual" called baz. Multiple packages with the same virtual
provider can be installed on a system; however, if a user runs
apk add baz they will provided a list of
packages that provide baz and must select one and install it.
provider_priorityprovides virtual provider.replacessomaskAPKBUILD when calculating providers
and dependencies. For example, internal libraries that are found in
ldpath but not in a normal path searched by the
dynamic linker should probably be listed here.subpackages$pkgname-dev for
development files (such as /usr/include and static library files) and
$pkgname-doc for documentation (such as
/usr/share/doc and /usr/share/man).
Each subpackage may be specified using three different
methods. The first, and most common, is
$pkgname-foo where foo
is the name of the split function specified later in the file. Similar
to the package function, the
foo function must move files from
$pkgdir or $srcdir to
$subpkgdir after creating
$subpkgdir.
The second method is to simply call the subpackage
foo which will create a package called
foo instead of pkgname-foo.
However, foo in both of these examples
cannot contain a hyphen, as shell function names cannot have hyphens in
them. In this case, the third method may be used:
foo:funcname where foo
is the name of the subpackage and funcname is
the name of the shell function in the APKBUILD
that creates it.
Note that an additional colon may be used to specify an
architecture for the subpackage; typically, this is used for marking
miscellaneous files that are not architecture-specific as noarch. For
example, $pkgname-doc $pkgname-foo
$pkgname-foo-misc:foo_misc:noarch will create the $pkgname-doc
package using the doc function, the $pkgname-foo
package using the foo function, and the
$pkgname-foo-misc package using the foo_misc
function and set $pkgname-foo-misc as noarch.
triggers$pkgname.trigger=/usr/share/man:/usr/local/share/man
This will run the package trigger script whenever files in /usr/share/man or /usr/local/share/man are created, modified, or removed.
The options variable allows you to set
parameters for the package at build time. There are a number of valid
options you may set, and you may set multiple options by writing a space
between each one.
!archcheckcharset.alias!checkcheckretrycheckroot cannot be used in the same
package; checkretry will take precedence.checkrootcheckx11xwud -in /tmp/Xvfb_screen0 if desired.!dbgDEFAULT_DBG is
set in the environment or abuild.conf(5). It is
typically used on packages that do not generate debug information (such as
pure Python packages) or packages that do not support debug information
packages.!fhsldpath-recursive---recursive argument to
scanelf(1) when attempting to find shared library (.so)
dependencies for the package.libtoolnet!stripDEFAULT_DBG.suidtextrelstoolchaing++.!tracedepsdepends with shared library (.so) or
symlink target dependencies.The following variables are defined for you by abuild(1), but may be overridden if necessary.
builddirbuilddir.pkgdirmake DESTDIR="$pkgdir"
install or similar to install the files. The default value is
$startdir/pkg and you should not modify this
variable.srcdirsource are downloaded and unpacked. The default
value is $startdir/src and you should not need to
modify this.startdirAPKBUILD file
resides.subpkgdirThe following variables are used only in special circumstances, and may be required or optional depending on their usage and the contents of other variables.
depends_devgiturlabuild checkout. If the default branch of the
repository is not desired, a different one may be specified by appending
-b branch where
branch is the branch to checkout.Functions specified here may be present in any
APKBUILD file, but with the exception of
package, are not strictly required.
fetchsource.unpacksource to
srcdir.preparesrcdir to be built. The
default prepare function ensures the build
directories are set up correctly and applies any *.patch files specified
in source. You must call
default_prepare if you write a custom
prepare function.buildbuilddir. You must
implement this function yourself. If no compilation is required, you may
omit it.check!check was specified in
options.packagepkgdir. Note that
pkgdir is not created for you; if this package
installs no files (for example, a metapackage), you must use
mkdir -p $pkgdir to skip the package phase.An install script is run when an action is taken on a package by
apk(8). An install script must be written in shell and
must have a #!/bin/sh interpreter declaration as the
first line. The install variable must contain the
install scripts needed by the package.
The install script will be run inside the root filesystem where the package is being installed. A single argument will be passed to all scripts, which is the version of the package being currently installed (or deinstalled). The pre-upgrade and post-upgrade scripts will have an additional second argument, which specifies the version of the package before the upgrade process.
The different actions that may have install scripts specified are as follows:
$pkgname.pre-installpkggroups and
pkgusers.$pkgname.post-installapk fix command will attempt to
re-run the post-install script if this occurs.$pkgname.pre-upgrade$pkgname.post-upgradeapk fix command will attempt to re-run
the post-upgrade script if this occurs.$pkgname.pre-deinstall$pkgname.post-deinstallCurrently, APKBUILD files are sourced as
normal shell scripts. This may change at a later date.
The abuild(1) utility as distributed by Alpine uses the BusyBox Almquist shell, a part of busybox(1) that is currently undocumented. It is mostly compliant with IEEE Std 1003.2 (“POSIX.2”) with some bash-like extensions, but this cannot be relied upon. The abuild(1) utility as distributed by Adélie uses the user's preferred /bin/sh, which is typically bash(1). It is highly recommended that package functions comply with IEEE Std 1003.2 (“POSIX.2”) for maximum compatibility.
The SPDX license reference (on the Web at <https://spdx.org/licenses/>), abuild(1), newapkbuild(1), apk(8).
The APKBUILD format and
abuild(1) utility first appeared in Alpine Linux 1.9.
Timo Teräs
<timo.teras@iki.fi>
Natanael Copa
<ncopa@alpinelinux.org>
Documentation:
A. Wilcox
<awilfox@adelielinux.org>
| February 13, 2018 | Adelie Linux |