维护 AUR 软件包

Arch User Repository 存储包含软件包配方的 Git 仓库，而不是已构建的软件包。 因此，维护 AUR 软件包意味着发布可审查的 PKGBUILD 和匹配的 .SRCINFO， 然后在隔离的构建环境中验证该配方。

正确描述软件包 #

PKGBUILD 定义 pkgname、pkgver、pkgrel、arch、许可证、源、校验和和依赖数组等元数据。 其函数划分各个阶段：

• prepare() 应用补丁或准备源代码。
• build() 编译或生成软件。
• check() 运行测试，并需要 checkdepends。
• package() 只在 $pkgdir 下安装文件。

使用 $srcdir 保存源代码和构建状态；软件包函数绝不能写入主机文件系统。 在 depends 中声明运行时依赖，在 makedepends 中声明仅构建工具， 在 checkdepends 中声明仅测试软件包。缺失的声明可能在开发者工作站上隐藏， 但会导致用户构建失败。

检查每个源 URL、补丁和 shell 表达式，因为 makepkg 会以调用用户的权限执行配方。 将发布软件包固定到不可变的上游工件，并使用校验和。上游发布签名版本时， 通过 validpgpkeys 验证签名；校验和能检测字节变化，但不能建立源的可信性。

在干净 chroot 中构建和检查 #

不要以 root 身份运行 makepkg。在干净 chroot 中构建，以便主机依赖、配置和过时的构建工件 不会使不完整的配方通过。配置好 devtools 后：

extra-x86_64-build

在 chroot 外进行本地迭代时，从干净的源代码树开始，并允许 makepkg 解析仓库依赖：

makepkg --cleanbuild --syncdeps

--syncdeps 会调用 pacman，因此无法获取 AUR 依赖。先审查并构建这些依赖， 然后通过本地仓库或 chroot 工作流提供经过验证的软件包。

安装前检查软件包内容并执行静态检查：

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

namcap 报告启发式结果，而不是证明。应在一次性环境中测试安装、升级、删除、 运行时依赖、服务和桌面集成。

更新版本和 VCS 软件包 #

发布更新时，修改 pkgver，在适当时重置 pkgrel，审查源和校验和后更新它们并重新构建。 不要使用 --skipinteg 让变化后的源通过检查。

VCS 软件包通常使用 -git 等后缀，并使用根据仓库历史派生版本的 pkgver() 函数。 其源必须在一次构建期间解析到可复现的修订版本。不要将发布软件包改成跟踪移动分支： 用户需要版本化、可审查的源输入和可预测的升级行为。

条件允许时，比较多次干净 chroot 构建。输出差异可能暴露时间戳、区域设置、构建路径或未声明输入， 这些因素会阻止可复现构建。

发布匹配的 AUR 元数据 #

从当前 PKGBUILD 生成 .SRCINFO；不要手动编辑它。 只提交已跟踪的 AUR 打包文件，并在推送前检查暂存区差异：

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

每次元数据更改都更新 .SRCINFO，包括依赖、源和拆分软件包。 使用可复现证据回应报告，在提交消息或软件包评论中说明破坏性变更， 并避免推送未经审查的用户补丁。AUR 孤儿化和删除是仓库维护流程； 它们不会使软件包成为官方 Arch 仓库的一部分。