'''Configuration files''' should be placed in the {{ic|/etc}} directory. If there is more than one configuration file, it is customary to '''use a subdirectory''' in order to keep the {{ic|/etc}} area as clean as possible. Use {{ic|/etc/{pkgname}/}} where {{ic|<nowiki>{pkgname}</nowiki>}} is the name of the package (or a suitable alternative, eg, apache uses {{ic|/etc/httpd/}}).

Makepkg duties

When makepkg is used to build a package, it does the
following automatically:

Checks if package dependencies and makedepends are installed

Downloads source files from servers

Checks the integrity of source files

Unpacks source files

Does any necessary patching

Builds the software and installs it in a fake
root

Strips symbols from binaries

Strips debugging symbols from libraries

Compresses manual and, or info pages

Generates the package meta file which is included with each package

Compresses the fake root into the package file

Stores the package file in the configured destination directory (cwd by default)

Architectures

The arch array should contain 'i686' and/or 'x86_64' depending on which architectures it can be built on. You can also use 'any' for architecture independent packages.

Licenses

The license array is being implemented in the official repos, and it should be used in your packages as well. Use it as follows:

A licenses package has been created in [core] that stores common licenses in /usr/share/licenses/common ie. /usr/share/licenses/common/GPL. If a package is licensed under one of these licenses, the licenses variable will be set to the directory name e.g. license=('GPL')

If the appropriate license is not included in the official licenses package, several things must be done:

The license file(s) should be included in /usr/share/licenses/$pkgname/ e.g. /usr/share/licenses/dibfoo/LICENSE. One good way to do this is by using:

If the source tarball does NOT contain the license details and the license is only displayed on a website for example, then copy the license to a file and include it. Remember to call it something appropriate too.

Add 'custom' to the licenses array. Optionally, you can replace 'custom' with 'custom:"name of license"'.

Once a licenses is used in two or more packages in an official repo, including [community], it becomes common

The MIT, BSD, zlib/libpng and Python licenses are special cases and cannot be included in the 'common' licenses pkg. For the sake of the license variable, it is treated like a common license (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) but for the sake of the filesystem, it is a custom license, because each one has its own copyright line. Each MIT, BSD, zlib/libpng or Python licensed package should have its unique license stored in /usr/share/licenses/$pkgname/.

Some packages may not be covered by a single license. In these cases multiple entries may be made in the license array e.g. license=("GPL" "custom:some commercial license"). For the majority of packages these licenses apply in different cases, as opposed to applying at the same time. When pacman gets the ability to filter on licenses (so you can say, "I only want GPL and BSD licensed software") dual (or more) licenses will be treated by pacman using OR, rather than AND logic, thus pacman will consider the above example as GPL licensed software, regardless of the other licenses listed.

The (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:

(L)GPL - (L)GPLv2 or any later version

(L)GPL2 - (L)GPL2 only

(L)GPL3 - (L)GPL3 or any later version

Submitting packages to the AUR

Note the following before submitting any packages to the AUR:

The submitted PKGBUILDs MUST NOT build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages having extra features enabled and/or patches in compare to the official ones. In such an occasion the pkgname array should be different to express that difference.
eg. A GNU screen PKGBUILD submitted containing the sidebar patch, could be named screen-sidebar etc. Additionally the provides=('screen') PKGBUILD array should be used in order to avoid conflicts with the official package.

To ensure the security of pkgs submitted to the AUR please ensure that you have correctly filled the md5sum field. The md5sum's can be generated using the makepkg -g command.

Please add a comment line to the top of the
PKGBUILD file that follows this format. Remember to disguise
your email to protect against spam:

# Maintainer: Your Name <address at domain dot com>

If you are assuming the role of maintainer for an existing PKGBUILD, add your name to the top as described above and change the title of the previous Maintainer(s) to Contributor:

Verify the package dependencies (eg, run
ldd on dynamic executables, check tools required
by scripts, etc).
The TU team strongly recommend the use of the
namcap utility, written by Jason Chu (jason@archlinux.org), to analyze the
sanity of packages. namcap will warn you about
bad permissions, missing dependencies, un-needed dependencies,
and other common mistakes. You can install the
namcap package with pacman.
Remember namcap can be used to check both pkg.tar.gz files and PKGBUILDs

Dependencies
are the most common packaging error. Namcap can help detect them, but
it is not always correct. Verify dependencies by looking at source
documentation and the program website.

Do not use replaces in a PKGBUILD unless the package is to be renamed, for example when Ethereal became Wireshark. If the package is an alternate version of an already existing package, use conflicts (and provides if that package is required by others). The main difference is: after syncing (-Sy) pacman immediately wants to replace an installed, 'offending' package upon encountering a package with the matching replaces anywhere in its repositories; conflicts on the other hand is only evaluated when actually installing the package, which is usually the desired behavior because it is less invasive.

All files uploaded to the AUR should be contained in a compressed tar
file containing a directory with the PKGBUILD and additional build files (patches, install, ...) in it.

foo/PKGBUILD
foo/foo.install
foo/foo_bar.diff
foo/foo.rc.conf

The archive name should contain the name of the package
e.g. foo.tar.gz.

One can easily build a tarball containing all the required files by using makepkg --source. This
makes a tarball named $pkgname-$pkgver-$pkgrel.src.tar.gz, which can then be uploaded to the AUR.

The tarball should not contain the binary tarball created by makepkg, nor should it contain the filelist

Additional guidelines

Be sure to read the above guidelines first - important points are listed on this page that will not be repeated in the following guideline pages. These specific guidelines are intended as an addition to the standards listed on this page.