AUR 软件包依赖

AUR 仓库提供的是 PKGBUILD，即可执行的软件包元数据，而不是二进制软件包或依赖解析器。因此，要安全地构建软件包，必须区分使构建成为可能的依赖项与安装到最终系统中的依赖项。

PKGBUILD 中的依赖类别 #

PKGBUILD(5) 定义了生命周期不同的依赖数组：

• depends 声明运行已安装软件包所需的软件包。
• makedepends 声明仅在构建期间需要的工具和库。
• checkdepends 声明 check() 所需的软件包。

版本约束使用 pacman 的依赖语法，例如 depends=('libfoo>=2')。拆分软件包可以使用特定于软件包的依赖数组，例如 package_client() { depends=('libclient') }。

不要仅仅因为软件包没有某个运行时库也能构建，就将该库移入 makedepends。反之，如果没有任何已安装文件需要编译器，也不要将编译器保留在 depends 中。准确的依赖数组可以让 pacman 正确规划升级和删除操作。

makepkg 负责构建；pacman 负责安装 #

请以非特权用户运行 makepkg。它会下载并验证源代码、检查依赖项、执行 prepare()、build()、check() 和 package()，然后创建供 pacman 使用的归档文件。makepkg -i 只会在构建成功后安装该归档文件；实际执行安装的是 pacman。

git clone https://aur.archlinux.org/example.git
cd example
makepkg --cleanbuild --syncdeps
sudo pacman -U ./*.pkg.tar.zst

--syncdeps 会要求 pacman 安装缺失的依赖项。因此，它只能解析已配置的二进制仓库中可用的软件包。AUR 分发的是构建配方，而不是仓库软件包，所以 --syncdeps 无法获取 AUR 依赖项。

避免使用 --nodeps，也绝不要使用 sudo 运行 makepkg；绕过依赖检查可能生成链接不正确的软件包，而以 root 身份执行未经审查的 PKGBUILD shell 代码会赋予其不必要的权限。

构建 AUR 依赖链 #

按照依赖顺序解析 AUR 依赖项。执行每个配方前都要检查它，先构建依赖链的叶节点，再安装生成的归档文件，从而使下一个软件包的依赖测试能够成功。

# Build and install the AUR dependency first.
git clone https://aur.archlinux.org/example-library.git
cd example-library
makepkg --cleanbuild --syncdeps
sudo pacman -U ./*.pkg.tar.zst

# Then build the dependent package.
cd ../example
makepkg --cleanbuild --syncdeps

AUR helper 可以自动遍历依赖图，但不能替代审查：每个 PKGBUILD、.SRCINFO、源代码 URL、补丁和安装脚本，都是受信任构建输入的一部分。构建前，请检查完整依赖链中的版本约束。

使用干净的 chroot 确保可复现性 #

主机上已安装的软件包可能掩盖未声明的依赖项。干净的 chroot 从定义明确的 Arch 基础环境开始，因此可以暴露缺失的 makedepends 和 checkdepends。配置好 devtools 后，在软件包目录中运行：

extra-x86_64-build

将前置 AUR 软件包构建到本地仓库中，或在构建依赖软件包之前，将经过验证的归档文件安装到 chroot 中。测试依赖链时，应有意重新创建或更新 chroot，并保留构建日志和软件包归档以供调查。干净 chroot 构建成功能够证明已声明的构建输入，但不能证明配方或其上游源代码是安全的。