An file is used by tools such as to build a package for eventual installation by the package manager. It defines metadata such as the name of the package, the version information, the source li‐ cense, and contact information for the developer. It addition‐ ally contains the commands needed to build, test, and install the package. The format is similar to a typical shell script; you set pre‐defined variables and implement pre‐defined functions, and the (or similar) utility will use them to create the package. The following variables must be set in all files: Specifies name of the package. This is typically the name of the package up‐ stream; however, note that all letters must be lowercased. Li‐ braries for scripting languages should have a prefix before the library name describing the language. Such prefixes include and 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. Specifies the version of the software being packaged. The version of a package must consist of one or more numbers separated by the radix (decimal point). The final number may have a single letter following it, for upstreams that use such a versioning scheme (such as 1.5a, 1.5b, 1.5c). After the final number (and optional single letter), a suffix may be ap‐ pended, which must be an underscore (_) followed by one of or op‐ tionally followed by another number. If the suffix is or it is considered to be earlier than the version without a suffix; if the suffix is or it is considered to be later than the version without a suffix. All of the following examples are valid ver‐ sions, 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 Specifies the package release number of this particular package version. This indi‐ cates when a package has changed without a corresponding change in version. Always increment when you change the contents, de‐ pendencies, or metadata of a package. The first release of a package is always Specifies what the package contains. must be 128 characters or less, and should concisely describe what ac‐ tions the software or items being packaged will allow the user to perform. For example, would be a sufficient for AbiWord. Speci‐ fies the Web address of the package’s upstream. This allows users and future maintainers to find documentation, release in‐ formation, and contact information for the package. If no Web address is available for the package, you must set to an empty string (""). Specifies the architectures for which the package may be built. It is highly recommended that you set this vari‐ able to "all" if the package is portable. You 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. Specifies the license under which the package is distributed. The value provided must match a SPDX license iden‐ tifier. Specifies the location of both local and remote source files used to build the package. Typically, the remote source file(s) or archive(s) is specified, followed by any local patches, install scripts, configuration files, or other necessary files. The following variables are not required, but may be set in any file: Specifies test‐time dependencies of the package. Common packages that are used for testing include check, dejagnu, and perl‐test‐command. Specifies the run‐time dependencies of the package. The utility will automatically scan the resultant package for shared library (.so) dependencies; do not specify them here. Specifies install scripts for the package, if any. See for more information about install scripts. Specifies a con‐ dition when should automatically install the package (or subpack‐ age). For instance, the OpenRC subpackages set to which means that the OpenRC subpackage will be automatically installed if the origin package and OpenRC are both installed on the same com‐ puter. Specifies build dependencies for the package. Specifies a space‐separated list of login groups to create during build‐ time. Note that you will need to create the login groups in a pre‐install install script as well; see for more information about install scripts. Specifies a space‐separated list of user logins to create during build‐time. Note that you will ned to create the user logins in a pre‐install install script as well; see for more information about install scripts. Specifies that the package "provides" the same contents as another package. There are two formats that you may use for a provider name, and a provider name with version. Specifying a provider name with ver‐ sion such as will cause the package to be an "alias" of foobar version 1.2. It will be automatically installed if a user then runs or similar, and it will conflict with a package named foo‐ bar. Specifying a provider name without a version such as 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 they will provided a list of packages that provide baz and must select one and install it. Specifies the numeric value for to use for the package when con‐ sidering which provider should be installed for the same virtual provider. Specifies packages that the package replaces. This is typically used for packages renamed by upstream. Specifies sub‐ packages or split packages built with this package. Typically, this will include for development files (such as /usr/include and static library files) and for documentation (such as /usr/share/doc and /usr/share/man). Each subpackage may be spec‐ ified using three different methods. The first, and most common, is where is the name of the split function specified later in the file. Similar to the function, the function must move files from or to after creating The second method is to simply call the sub‐ package which will create a package called instead of pkgname‐ foo. However, 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: where is the name of the sub‐ package and is the name of the shell function in the that creates it. Note that an additional colon may be used to specify an ar‐ chitecture for the subpackage; typically, this is used for mark‐ ing miscellaneous files that are not architecture‐specific as noarch. For example, will create the $pkgname‐doc package using the function, the $pkgname‐foo package using the function, and the $pkgname‐foo‐misc package using the function and set $pkg‐ name‐foo‐misc as noarch. Specifies a trigger script used by the package. A trigger script is a shell script that is called when‐ ever monitored files or directories are modified. You may spec‐ ify the paths to monitor using the triggers variable as follows: This will run the package trigger script whenever files in or are created, modified, or removed. The 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. Specifies that the package contains binaries that cannot run on the target architecture. This is primarily used for packages containing firmware, and should typically never need to be used. Specifies that the pack‐ age ships a /usr/lib/charset.alias file and that it should be in‐ stalled on the user’s system. This is almost never the case. Do not use this option. Specifies that the package will not run a test suite. The reason for disabling the check phase should be noted in a comment. Specifies that the package’s test suite will be run in This is necessary for some test suites which fail when run as non‐root. Specifies that the package should not be built with a debug information package. This is the default unless is set in the environment or 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. Specifies that the package violates FHS and installs to a loca‐ tion such as or Specifies that should use the argument to when attempting to find shared library (.so) dependencies for the package. Specifies that the package requires its libtool (.la) files. They will not be automatically removed by Specifies that the package build system requires access to a network. This is discouraged and an issue should be filed with the package’s au‐ thors. Specifies that should not be run on any of the package’s binaries. This is automatically implied if the ‐dbg subpackage is enabled, or if you are using Specifies that binaries in the package may be installed set‐uid. This is a security risk and it is highly recommended to use capabilities or process separation instead of set‐uid where available. Specifies that the package’s binaries are known to contain relocations against text segments. By default, will refuse to create such a package because this is a security concern. Specifies that the package is part of the base toolchain set and may depend on packages like Specifies that should not automatically populate with shared library (.so) or symlink target dependencies. The following variables are defined for you by but may be overridden if necessary. Specifies the di‐ rectory where the source code of the package will be built. The default value is which is appropriate for most source distribu‐ tions. If the source tarball does not create a $pkgname‐$pkgver directory when it is unpacked, you must override Specifies the directory where the built files will be installed. Typically, you will call or similar to install the files. The default value is and you should not modify this variable. Specifies the direc‐ tory where the files specified in are downloaded and unpacked. The default value is and you should not need to modify this. Specifies the directory where the file resides. Specifies the directory where the subpackage’s files should be placed. This variable is only set inside subpackage functions. The following variables are used only in special circumstances, and may be re‐ quired or optional depending on their usage and the contents of other variables. Specifies the run‐time dependencies of the ‐dev subpackage. Specifies the URL of the Git repository to use with If the default branch of the repository is not desired, a differ‐ ent one may be specified by appending where is the branch to checkout. Functions specified here may be present in any file, but with the exception of are not strictly required. This func‐ tion is called to download the remote files in This function un‐ packs any archives in to Prepares the source in to be built. The default function ensures the build directories are set up cor‐ rectly and applies any *.patch files specified in You must call if you write a custom function. Compiles the source in You must implement this function yourself. If no compilation is required, you may omit it. Runs the package’s test suite. This function must be implemented unless was specified in Installs the package into Note that is not created for you; if this package installs no files (for example, a metapackage), you must use to skip the package phase. An install script is run when an action is taken on a package by An install script must be written in shell and must have a interpreter declaration as the first line. The vari‐ able 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 dif‐ ferent actions that may have install scripts specified are as follows: Executed before the package is installed. If this script exits with an error (non‐zero exit code), will halt the installation and the package will not be installed. This install script is typically used to create any users or groups needed as described in and Executed after the package is installed. If this script exits with an error (non‐zero exit code), will mark the package as broken. The command will attempt to re‐run the post‐install script if this occurs. Executed before the package is upgraded. If this script exits with an error (non‐zero exit code), will mark the package as broken. Executed after the pack‐ age is upgraded. If this script exits with an error (non‐zero exit code), will mark the package as broken. The command will attempt to re‐run the post‐upgrade script if this occurs. Exe‐ cuted before the package is removed from the system. If this script exits with an error (non‐zero exit code), will not remove the package from the system. Executed after the package is re‐ moved from the system. Exiting with an error will have no ef‐ fect. Currently, files are sourced as normal shell scripts. This may change at a later date. The utility as distributed by Alpine uses the BusyBox Almquist shell, a part of that is cur‐ rently undocumented. It is mostly compliant with with some bash‐ like extensions, but this cannot be relied upon. The utility as distributed by Adélie uses the user’s preferred /bin/sh, which is typically It is highly recommended that package functions com‐ ply with for maximum compatibility. The SPDX license reference (on the Web at ), The format and utility first appeared in Alpine Linux 1.9. Documentation: