在Arch Linux上，官方存储库为：核心，额外和社区。这些软件包已被编译，并通过安装pacman。在大多数情况下，一般用户可以忽略这3个正式存储库是分开的。Core包含最关键的软件包，例如内核，引导过程，网络，软件包管理，openssh等。在发布新版本之前，它还具有更严格的测试要求。Extra包含其他不太重要的流行软件包，例如X服务器，窗口管理器或Web浏览器。社区包含不太受欢迎的软件包。只有受信任的用户（大约60位其他受信任的用户投票的活动用户）有权更改正式存储库。

在2019年，官方资料库（https://www.archlinux.org/packages）中约有11,000个软件包。但是，Linux上还有许多其他程序可用。因此，存在AUR（Arch Linux用户存储库），因此任何Arch用户都可以添加新程序并成为其维护者，或者采用没有当前维护者的“孤立”程序包。AUR中大约有55,000个软件包，位于https://aur.archlinux.org/。

AUR有3个关键差异：

1. 同样，这些包装可以由任何用户生产，甚至是全新的。
2. AUR仅包含一个PKGBUILD外壳脚本（用于自动制作程序包），而不是已编译的二进制文件，该脚本可以自动生成程序包。（有时它也包含小的文本补丁，或安装/升级/卸载外壳程序脚本）。这在允许任何用户做出贡献的同时完成了巨大的工作，同时减轻了某人能够分发恶意代码的机会。对于AUR软件包的问题，​​Arch社区仍然很有帮助，但是请注意，使用它们的风险由您自己承担。因为它提供的只是一个PKGBUILD，所以最终您有责任查看PKGBUILD将要使用的a。（当然，许多用户不这样做，而只是依靠其他人来监视。）
3. 由于pacman不直接与AUR交互，因此您有责任更新AUR软件包。当您通过定期升级整个系统时pacman，它不会自动将更新下载到AUR PKGBUILD文件，进行编译并为您安装。

尽管本文着重于从AUR构建软件包，但可以使用相同的技术自己从官方存储库构建软件包。

PKGBUILD

与.spec许多其他发行版使用的文件相比，a PKGBUILD是一个简短的shell脚本。尽管某些软件包更复杂，但它们可以类似于以下内容：

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc='DESCRIPTION'
url=http://example.com/
arch=('x86_64')
license=('GPL2')
source=(http://example.com/downloads/${pkgname}-${pkgver}.tar.gz)
sha256sums=('f0a90db8694fb34685ecd645d97d728b880a6c15c95e7d0700596028bd8bc0f9')

build() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   ./configure
   make
}

package() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   make install
}

该文档指的是：

• PKGNAME：包装名称
• PKGVER：软件包的版本（几乎总是与上游版本号匹配）
• PKGREL：PKGBUILD特定版本的Arch的“版本” PKGVER（通常为1，但如果需要PKGBUILD在上游发行版之间进行更改，则递增）
• ARCH：可以构建该软件包的体系结构（有些传统，因为Arch Linux官方存储库仅支持“ x86_64”（64位CPU），但是AUR软件包仍可以支持“ i686”（32位CPU）或“任何”指定架构是不相关的）
• PKGBUILD/ETC：AUR存储库中实际存在的所有文件；的PKGBUILD，和任何其他小的文本补丁或安装/升级/卸载的shell脚本。在source阵列中不包括上游文件。

尽管AUR已被证明是非常值得信赖的，但最好看一看以PKGBUILD/ETC确保它是从您愿意信任的地方获取资源的。（例如，一个官方的上游位置，可以来自github-但不仅仅是与上游软件包无关的某个随机人的github存储库）；并且其中PKGBUILD/ETC不包含任何可疑代码。

取得 PKGBUILD/ETC

从AUR

如果官方存储库不包含您要安装的软件包，请在https://aur.archlinux.org/上进行搜索。希望您会发现您所寻找的东西是存在的，最新的并得以维护。

PKGBUILD/ETC从AUR 获得的最好方法是通过克隆它git。

git如果尚未安装，请安装：

# pacman -S git

使用该软件包的AUR网站上显示的“ Git Clone URL”：

$ git clone https://aur.archlinux.org/fslint.git

输入目录并查看其内容。（一切都在这里上市，除了. .. .git是PKGBUILD/ETC）：

$ cd <PKGNAME>
$ ls -a
.  ..  .git  PKGBUILD  .SRCINFO

如果您进行检查PKGBUILD，您将希望看到它使用了官方的上游源代码，并执行了构建软件包的典型步骤，因此似乎值得信赖。该文件.SRCINFO包含网站上显示的有关该程序包的信息，因此不必担心。如果此处还有其他文件，则上游不会（直接）提供这些文件，因此PKGBUILD应检查文件及其在文件中的使用方式，以确保其中不包含任何可疑文件。

来自官方资料库

尽管需要的频率要少得多，但是您可以构建官方存储库中已经存在的软件包，以包括新的补丁程序，构建较新的版本等。

PKGBUILD/ETC从核心和额外存储库中获取：

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/packages.git "<PKGNAME>"

从社区存储库：

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/community.git "<PKGNAME>"

升级中 PKGBUILD/ETC

如果PKGBUILD/ETC发布了升级版，则可以返回使用创建的该目录git clone，并更新它们：

$ git pull

然后，使用下面选择的方法重新编译和升级软件包。

编译中

有很多方法可以编译软件包。最终，一切都使用makepkg。有2种官方支持的方式：

• 要直接使用makepkg，请参见 http://www.codejie.net/6167.html。
• 要间接使用makepkg干净chroot，请参见http://www.codejie.net/6162.html。

有许多AUR辅助程序，（如makepkg包装），未正式拱支，如aurutils，yay和最近停产aurman和yaourt。即使您使用这些其他帮助程序之一，也强烈建议您熟悉官方支持的方法，以便在出现问题时更加有效。

本文档的其余部分将YOUR BUILDER用来表示您选择的任何一种方法。

本地存储库

您可以将本地存储库设置为所构建的所有软件包的中央位置。

将本地存储库放置在您想要的任何地方：

# mkdir /archLocalRepo

在YOUR BUILDER没有任何自动安装选项的情况下运行，并将软件包复制到本地存储库中。

# cp <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz /archLocalRepo

将新包添加到存储库索引：

# repo-add /archLocalRepo/archLocalRepo.db.tar.gz /archLocalRepo/<PACKAGE-FILE-NAME>

要从存储库的索引和包文件本身中删除包：

# repo-remove /archLocalRepo/archLocalRepo.db.tar.gz <PKGNAME>
# rm /archLocalRepo/<PACKAGE-FILE-NAME>

如果需要替换现有的软件包文件，则需要单独删除要替换的软件包，然后添加新的。您不能简单地将新文件复制到旧文件上。

pacman通过编辑配置使用本地存储库，/etc/pacman.conf并在末尾添加以下内容：

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

您需要pacman刷新其关于存储库（包括本地数据库），数据库的知识；查看您已添加到其中的软件包：

# pacman -Sy

然后，您可以安装该软件包，与安装在官方存储库中的软件包没有什么不同：

# pacman -S <PKGNAME>

请注意，如果该软件包只是要安装的另一个软件包的依赖项，则不需要直接安装它。当您安装另一个软件包时，pacman它将自动在本地存储库中查找并安装依赖项软件包。

编译更快

默认情况下，YOUR BUILDER使用单个线程进行编译。在多CP​​U系统上，可以允许使用多个线程。构建系统将在可能的情况下并行编译部分源代码。有时代码的一部分需要与之交互的其他部分才能被编译，因此您将不会总是看到允许使用的线程数。编辑/etc/makepkg.conf。

要允许使用与虚拟内核一样多的线程，请添加以下内容：

MAKEFLAGS="-j$(nproc)"

注意： 这将nproc每次都运行命令，因此，如果您升级Vultr服务器，它将始终使用当前内核数。

要允许使用多个虚拟内核（但不是全部），以减少对整体系统性能的影响，请添加特定数量。例如，如果您有24个核心，则可以允许使用21个核心：

MAKEFLAGS="-j21"

指定的线程数多于您拥有的虚拟核心数，将会降低性能。

这是相当罕见的，但是某些软件包的构建系统由于没有正确定义代码部分之间的依赖关系而存在并行编译问题。通常，这些包的PKGBUILD文件将通过调用来为您处理make -j1，该设置将覆盖您设置的默认设置。如果需要它并且缺少它，请向Arch软件包维护者报告。

PGP签名错误

甲PKGBUILD源阵列可以包含.asc或.sig文件。它们通常包含在bash括号扩展中，因此很容易错过：

source=("http://example.com/downloads/${pkgname}-${pkgver}.tar.gz{,.sig}")

如果源阵列中包括以下两种格式的签名文件中的任一种，则将YOUR BUILDER自动尝试验证上游源档案的签名。签名的PGP密钥必须在用户的密钥环中；否则，它将因错误而中止：

==> Verifying source file signatures with gpg...
    <SOURCE-FILE> ... FAILED (unknown public key 1234567890ABCDEF)
==> ERROR: One or more PGP signatures could not be verified!

了解GPG密钥可以通过几种方式显示很重要。它的指纹是40个十六进制字符，这是您应始终使用的指纹。长键ID是最后16位数字，而短键ID是最后8位数字。虽然较短是很方便的，但它允许重复，从而使验证签名后的整个推理无效。更糟糕的是，已知攻击者会为高知名度的开发人员生成与较短长度的密钥相匹配的伪密钥。

获取并验证PGP密钥指纹

如果尚未尝试构建软件包，请下载包含签名文件的源：（如果尝试构建，则已经存在）。

$ makepkg --nobuild --noextract

要获取完整的指纹：

$ gpg <ASC-OR-SIG-FILENAME>
...
gpg:                using RSA key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
...

理想情况下，您应该从上游验证此指纹。为了安全起见，上游应将其维护者的钥匙放在其网站上或来源中的某个位置。仅在密钥服务器上搜索密钥实际上并没有做任何事情。攻击者可以轻松地提交伪造的密钥，因为密钥服务器不验证真实性。密钥可以由其他密钥签名，因此，如果您已经拥有一个信任的密钥，则可以放心地信任它们已经签名的任何密钥。

这可能需要很多工作，尤其是当上游不发布其指纹或将其放置在易于找到的地方时。在PKGBUILD将包含一个validpgpkeys阵列，该阵列是由拱维护者加入。如果软件包是一个正式的存储库，则意味着一个受信任的用户将其放在了那里，并且您只要相信阵列中列出的任何内容，就应该是相当安全的。如果包裹在AUR中，请记住它只是意味着另一个Arch用户将其放在了那里。如果您担心信任它，可以随时调查用户以了解他们过去使用Arch所做的事情。

将PGP密钥添加到您的密钥环

要将指纹添加到您的钥匙圈：

$ gpg --recv-keys <FINGERPRINT>

您现在可以运行YOUR BUILDER，它将信任指纹。

AUR开发包

AUR包结尾的名称-git，-svn，-bzr或者-hg是发展的版本，它使用上游的最新版本控制系统提交，而不是上游的最新版本。例如，一个-git软件包将在master分支（或其等效分支）中使用上游的最新提交。这非常适合运行上游的错误修复和尚未发布的新功能，并且在处理上游的bug时报告的错误包括：您需要为他们验证这不是尚未在发行版中进行的提交所修复的错误。这些软件包应被视为潜在不稳定。就是说，不幸的是，有时别无选择，因为一些上游维护者从不标记发行版或在标记发行版之间过长，并期望每个人都使用其最新提交。根据软件包的不同，您可能是第一个尝试运行该提交的人。根据上游开发人员的不同，他们的最新提交甚至可能无法编译，

了解一个常见的错误很重要。不要仅仅因为AUR开发包显示的是旧版本号而将其标记为过时！开发性软件包PKGBUILD文件包含一个附加功能pkgver()，该功能用于自动分析PKGVER上游源代码中的更新。-git包的常见格式是<TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>。软件包可能在AUR中以列出5.0.0.r102.8d7b42ac21-1，因为这是其中PKGBUILD包含的内容。但是，当您创建一个包时，YOUR BUILDER将自动更新PKGVER以反映新下载的源代码。实际上，如果已经发布了许多新版本，但是在构建过程中没有发生任何变化，那么PKGBUILD列出旧版本可能会导致构建新得多的内容，例如9.1.2.r53.2c9a41b723-1。对于这些软件包，网站上列出的版本只是AUR维护者上次不得不更新时的最新版本PKGBUILD。

AUR维护者不应仅更新PKGVER来反映新版本。仅当较新的上游提交实际上需要PKGBUILD更改其他内容时，才应该这样做。

仅当您知道确实存在问题时，才标记过期的可开发AUR软件包。意思是，您实际上已经尝试使用它，但是它无法编译或解析格式正确的new PKGVER。有时会发生某些事情，迫使AUR维护者更新PKGBUILD，例如上游依赖关系更改，configure选项更改，新的GCC版本在源代码中获取以前版本没有的错误，上游存储库位置更改或上游开发人员将更改其典型版本的位置在源代码中，破坏了PKGVER解析功能。请理解，即使无法编译或无法正常工作，这也可能意味着AUR维护人员需要对其构建过程进行更改，或者可能是源代码的上游问题，而AUR维护人员不对此负责。

过期的包裹

在报告软件包过时之前，请务必阅读以上“ AUR开发软件包”部分！

如果上游为非开发性软件包发布了比中的较新版本PKGBUILD，则可以单击“标志软件包已过期”，然后向维护者输入一条消息。将https://packages.archlinux.org用于官方存储库软件包，将https://aur.archlinux.org用于AUR软件包。一个有用的消息是新的版本号，也许是发行公告或源代码的链接。标记功能会自动将您的消息通过电子邮件发送给维护者。

在AUR软件包上，如果两周后没有任何响应，则可以单击“提交请求”，键入“孤儿”，如果您想让受信任的用户删除当前的维护者，然后将该软件包设为孤儿，如果维护者不响应孤立请求。通常，人们只有在能够并且愿意接管软件包的情况下才提出孤儿请求，并且最好仅在他们已经有工作电流的情况下提出孤儿请求PKGBUILD。

同时，您通常可以自己更新过时的软件包。通常，您只需要通过将更改为新的版本号来更改a PKGBUILD，然后更新PKGVER完整性和。程序updpkgsums包中存在一个程序pacman-contrib，该程序会自动计算和并在中更新它们PKGBUILD。值得检查上游的发行说明，以查看它们是否提到在新版本的安装过程中需要进行任何更改。有时上游的变化需要更多的变化或大修PKGBUILD/ETC。通常，source数组会嵌入PKGVER其中，因此通常甚至不需要更新。