Users cansharePKGBUILD scripts using theArch User Repository. It does not contain any binary packages but allows users to uploadPKGBUILDs that can be downloaded by others. ThesePKGBUILDs are completely unofficial and have not been thoroughly vetted, so they should be used at your own risk.

If you are unsure in any way about the package or the build/submission process even after reading this section twice, submit thePKGBUILD to theAUR mailing list, theAUR forum on the Arch forums, or ask on ourIRC channel for public review before adding it to the AUR.

When submitting a package to the AUR, observe the following rules:

• The submittedPKGBUILDs must not build applicationsalready in any of theofficial binaryrepositories under any circumstances. Check theofficial package database for the package. If any version of it exists,do not submit the package. If the official package is out-of-date, flag it as such. If the official package is broken or is lacking a feature, then pleasefile a bug report.

Exception to this strict rule may only be packages havingextra features enabled and/orpatches in comparison to the official ones. In such an occasion thepkgname should be different to express that difference. For example, a package for GNU screen containing the sidebar patch could be namedscreen-sidebar. Additionally theconflicts=('screen') array should be used in order to avoid conflicts with the official package.

• Check the AUR if the packagealready exists. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained or the maintainer is unresponsive, the package can be adopted and updated as required. Do not create duplicate packages.

• Make sure the package you want to upload isuseful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.

The AUR and official repositories are intended for packages which install general software and software-related content, including one or more of the following: executable(s); configuration file(s); online or offline documentation for specific software or the Arch Linux distribution as a whole; media intended to be used directly by software.

• Packages that do not support thex86_64 architecture arenot allowed in the AUR.

• Do not usereplaces in an AURPKGBUILD unless the package is to be renamed, for example whenEthereal becameWireshark. If the package is analternate version of an already existing package, useconflicts (andprovides 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 matchingreplaces 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.

• Packages that build from a version control system and are not tied to a specific version need to have an appropriate suffix,-git for git and so on, seeVCS package guidelines#Package naming for a full list.

• Packages that useprebuiltdeliverables, when the sources are available, must use the-bin suffix. An exception to this is withJava. The AUR should not contain the binary tarball created by makepkg, nor should it contain the filelist. If you are packaging a non-free software, see alsoNonfree applications package guidelines#Package naming regarding usage of-bin suffix.

• Packages that build from source using a specific version do not use a suffix.

• Please add acomment line to the top of thePKGBUILD file which contains information about the currentmaintainers and previouscontributors, respecting the following format. Remember to disguise your email to protect against spam. Additional lines are optional.

Note The use of obfuscation when it comes to email addresses makes it difficult for people to contact you.

If you are assuming the role of maintainer for an existingPKGBUILD, add your name to the top like this

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

If there were previous maintainers, put them as contributors. The same applies for the original submitter if this is not you. If you are a co-maintainer, add the names of the other current maintainers as well.

# Maintainer: Your name <address at domain dot tld># Maintainer: Other maintainer's name <address at domain dot tld># Contributor: Previous maintainer's name <address at domain dot tld># Contributor: Original submitter's name <address at domain dot tld>

• Add aLICENSE file and/or aREUSE.toml file to your repository. You are encouraged to follow theArch package guidelines#Package sources licenses and license your submission under the0BSD license.

Note Packages missing a license or containing a different license than0BSD arenot eligible for promotion to theofficial repositories.

For write access to the AUR, you need to have anSSH key pair. The content of the public key needs to be copied to your profile inMy Account, and the corresponding private key configured for theaur.archlinux.org host. For example:

~/.ssh/config

Host aur.archlinux.org  IdentityFile ~/.ssh/aur  User aur

You shouldcreate a new key pair rather than use an existing one, so that you can selectively revoke the keys should something happen:

$ ssh-keygen -f ~/.ssh/aur

If you arecreating a new package from scratch, establish a localGit repository and an AUR remote bycloning the intendedpkgbase. If the package does not yet exist, the following warning is expected:

$ git -c init.defaultBranch=master clone ssh://aur@aur.archlinux.org/pkgbase.git

Cloning into 'pkgbase'...warning: You appear to have cloned an empty repository.Checking connectivity... done.

If you already have a package,initialize it as a Git repository if it is not one:

$ git -c init.defaultBranch=master init

and add an AUR remote:

$ git remote addlabel ssh://aur@aur.archlinux.org/pkgbase.git

Thenfetch this remote to initialize it in the AUR.

When releasing a new version of the packaged software, update thepkgver orpkgrel variables to notify all users that an upgrade is needed. Do not update those values if only minor changes to thePKGBUILD such as the correction of a typo are being published.

Do not commit merepkgver bumps forVCS packages. They are not considered out of date when the upstream has new commits. Only do a new commit when other changes are introduced, such as changing the build process.

Be sure to regenerate.SRCINFO wheneverPKGBUILD metadata changes, such aspkgver() updates; otherwise the AUR will not show updated version numbers.

To upload or update a package:

• addat leastPKGBUILD and.SRCINFO,
• add any additional new or modified helper files (such as.install files orlocal source files such aspatches),
• add apackage source license,
• commit with a meaningful commit message,
• push the changes to the AUR.

For example:

$ makepkg --printsrcinfo > .SRCINFO$ git add PKGBUILD .SRCINFO$ git commit -m "useful commit message"$ git push

• Check for feedback and comments from other users and try to incorporate any improvements they suggest; consider it a learning process!
• Please do not leave a comment containing the version number every time you update the package. This keeps the comment section usable for valuable content mentioned above.
• Please do not just submit and forget about packages! It is the maintainer's job to maintain the package by checking for updates and improving thePKGBUILD.
• If you do not want to continue to maintain the package for some reason,disown the package using the AUR web interface and/or post a message to the AUR Mailing List. If all maintainers of an AUR package disown it, it will become an"orphaned" package.
• Automation is a valuable tool for maintainers, but it can not replacemanual intervention (e.g. projects can change license, add or remove dependencies, and other notable changes even for "minor" releases). AutomatedPKGBUILD updates are used at your own risk and any malfunctioning accounts and their packages may be removed without prior notice.

Deletion, merge, and orphan requests can be created by clicking on the "Submit Request" link under "Package Actions" on the right hand side. This dispatches notification emails to the current package maintainer and to theaur-requests mailing list for discussion.Package Maintainers will then either accept or reject the request.

Request tounlist apkgbase from the AUR. A short note explaining the reason for deletion is required, as well as supporting details (like when a package is provided by another package, if you are the maintainer yourself, it is renamed and the original owner agreed, etc).

Request to delete apkgbase and transfer its votes and comments to anotherpkgbase. The name of the package to merge into is required.

This is the action to use if, for example, an upstream hasrenamed their project.

Request that apkgbase be disowned. These requests will be granted after two weeks if the current maintainer did not react. The exception is if a package was flagged out-of-date for at least 180 days; orphan requests are then automatically accepted.

• About Arch
• Package development
• Package management