Maintaining AUR Packages

The Arch User Repository stores Git repositories containing package recipes, not built packages. Maintaining an AUR package therefore means publishing a reviewable PKGBUILD and matching .SRCINFO, then validating that recipe in an isolated build environment.

Model the Package Correctly #

A PKGBUILD defines metadata such as pkgname, pkgver, pkgrel, arch, license, sources, checksums, and dependency arrays. Its functions separate stages:

• prepare() applies patches or prepares sources.
• build() compiles or generates software.
• check() runs tests and requires checkdepends.
• package() installs only below $pkgdir.

Use $srcdir for sources and build state; never write into the host filesystem from a package function. State runtime dependencies in depends, build-only tools in makedepends, and test-only packages in checkdepends. Missing declarations can remain hidden on a developer workstation and fail for users.

Review every source URL, patch, and shell expression because makepkg executes the recipe with the invoking user’s privileges. Pin release packages to immutable upstream artifacts and use checksums. When upstream publishes signed releases, verify signatures through validpgpkeys; a checksum detects changed bytes but does not establish source trust.

Build and Inspect in a Clean Chroot #

Do not run makepkg as root. Build in a clean chroot so host dependencies, configuration, and stale build artifacts cannot make an incomplete recipe pass. With devtools configured:

extra-x86_64-build

For a local iteration outside the chroot, begin from a clean source tree and allow makepkg to resolve repository dependencies:

makepkg --cleanbuild --syncdeps

--syncdeps calls pacman, so it cannot retrieve AUR dependencies. Review and build those dependencies first, then provide their verified packages through a local repository or the chroot workflow.

Inspect the package payload and apply static checks before installation:

bsdtar -tf ./*.pkg.tar.zst
namcap PKGBUILD ./*.pkg.tar.zst

namcap reports heuristics, not proof. Test installation, upgrade, removal, runtime dependencies, services, and desktop integration in a disposable environment.

Update Versions and VCS Packages #

For a release update, change pkgver, reset pkgrel when appropriate, update sources and checksums after reviewing them, and rebuild. Do not use --skipinteg to make a changed source pass.

A VCS package conventionally uses a suffix such as -git and a pkgver() function derived from repository history. Its source must resolve to a reproducible revision during one build. Avoid converting a release package into a moving branch: users need versioned, reviewable source inputs and predictable upgrade behavior.

Compare repeated clean-chroot builds where practical. Differences in output can expose timestamps, locale, build paths, or undeclared inputs that prevent reproducibility.

Publish Matching AUR Metadata #

Generate .SRCINFO from the current PKGBUILD; do not hand-edit it. Commit only tracked AUR packaging files and inspect the staged diff before pushing:

makepkg --printsrcinfo > .SRCINFO
git add PKGBUILD .SRCINFO
git diff --cached
git commit
git push

Update .SRCINFO for every metadata change, including dependencies, sources, and split packages. Respond to reports with reproducible evidence, state breaking changes in commit messages or package comments, and avoid pushing unreviewed user patches. AUR orphaning and deletion are repository maintenance procedures; they do not make a package part of an official Arch repository.