官方软件仓库
软件仓库是用于获取并安装软件包的存储位置。
Arch Linux 官方软件仓库包含必不可少的和流行的软件，可以通过 pacman 方便地获取。它们由软件包维护者负责维护。
官方仓库中的软件包会持续升级：当一个包升级时，其旧版本将从仓库中移除。Arch 没有大版本发布的概念：每个软件包只要上游发布了新版本，就会进行升级。每个仓库始终保持一致性，即其托管的软件包版本始终相互兼容。
稳定版软件仓库
core
此仓库可以在你常用的镜像源中的 .../core/os/ 路径下找到。
core 包含用于以下用途的软件包：
以及上述项的依赖（不一定是 makedepends）和 base 元软件包 (meta package)。
core 有相当严格的质量要求。在软件包更新被接受之前，需要开发者/用户进行验证 (signoff)。对于使用率较低的软件包，合理的曝光就足够了：通知人们有关更新的信息、请求验证、根据更改的严重程度在 core-testing 中保留长达一周、没有未解决的错误报告，以及软件包维护者的隐式验证。
extra
此仓库可以在你常用的镜像源中的 .../extra/os/ 路径下找到。
extra 包含所有不属于 core 的软件包。此仓库由软件包维护者和 Arch 开发者共同维护。例如：Xorg、窗口管理器、Web 浏览器、媒体播放器、Python 和 Ruby 等语言工具，以及更多其他内容。
multilib
此仓库可以在你常用的镜像源中的 .../multilib/os/ 路径下找到。
multilib 包含 32 位软件和库，可用于在 64 位系统上运行和构建 32 位应用程序（例如 steam 等）。
启用 multilib 仓库后，32 位兼容库位于 /usr/lib32/ 下。
启用 multilib
要启用 multilib 仓库，请取消 /etc/pacman.conf 中 [multilib] 部分的注释。
/etc/pacman.conf
[multilib] Include = /etc/pacman.d/mirrorlist
然后升级系统并安装所需的 multilib 软件包。
pacman -Sl multilib 列出 multilib 仓库中的所有软件包。32 位库的软件包名称以 lib32- 开头。禁用 multilib
执行以下命令移除所有从 multilib 安装的软件包：
# pacman -R $(comm -12 <(pacman -Qq | sort) <(pacman -Slq multilib | sort))
如果与 gcc-libs 发生冲突，请重新安装 gcc-libs 软件包和 base-devel 软件包组的依赖项（参阅 Pacman/提示和技巧#软件包的依赖）。
error: no targets specified (use -h for help)，这意味着您的系统上没有安装来自 multilib 仓库的软件包。注释掉 /etc/pacman.conf 中的 [multilib] 部分。
/etc/pacman.conf
#[multilib] #Include = /etc/pacman.d/mirrorlist
然后升级系统。
测试版软件仓库
测试版 (testing) 软件仓库的目的是为进入主仓库之前的软件包提供一个暂存区域。软件包维护者（和普通用户）随后可以访问这些测试版软件包，以确保集成新软件包时没有问题。一旦软件包经过测试且未发现错误，该软件包就可以移至主仓库。
并非所有软件包都需要经过此测试过程。如果出现以下情况，新软件包会进入测试版仓库：
- 它们的目标是 core 仓库。core 中的所有内容都必须经过 core-testing。
- 它们在更新时可能会破坏某些内容，需要先进行测试。
- 它们会影响许多软件包（例如 perl 或 python）。
- 它们是由初级软件包维护者 (Junior Package Maintainer) 构建的。
测试版仓库通常也用于大型软件包合集的新版本发布，例如 GNOME 和 KDE。
- 测试版仓库可能包含预发布版本的软件。
- 启用测试版仓库时请务必小心。执行更新后系统可能会崩溃。只有知道如何处理潜在系统故障的经验丰富的用户才应使用它。
- 如果启用了 core-testing，则必须同时启用 extra-testing，反之亦然。如果你启用了以下子章节中列出的任何其他测试版仓库，则必须同时启用 core-testing 和 extra-testing。
- 由于并非主仓库中的所有软件包在测试版仓库中都有对应版本，因此应保留 core 和 extra 主仓库，并且相应的测试版仓库应位于主仓库之前。
core-testing
此仓库可以在你常用的镜像源中的 .../core-testing/os/ 路径下找到。
core-testing 包含 core 仓库的候选软件包。
core-testing 是唯一可能与任何其他官方仓库发生名称冲突的仓库。如果启用，它必须是你 /etc/pacman.conf 文件中列出的第一个仓库。
extra-testing
此仓库类似于 core-testing 仓库，但是用于 extra 仓库的候选软件包。
multilib-testing
此仓库类似于 core-testing 仓库，但是用于 multilib 仓库的候选软件包。
gnome-unstable
此仓库包含 GNOME 桌面环境的预发布版本（Alpha、Beta、RC）以及稳定版的测试包，然后再将其过渡到主要的 extra-testing 仓库。
要启用它，请将以下行添加到 /etc/pacman.conf：
/etc/pacman.conf
[gnome-unstable] Include = /etc/pacman.d/mirrorlist
gnome-unstable 条目应位于仓库列表的顶部（即，位于启用的 core-testing 条目之上；见上方的警告）。
请在 Arch 的 GitLab 中报告与打包相关的错误，而其他任何内容都应上报至 GNOME GitLab。
有关此仓库的其他协助和信息，请加入 Matrix 群组。
kde-unstable
此仓库包含 KDE Plasma 和 Applications 的最新 Beta 或 候选发布版 (Release Candidate)。
要启用它，请将以下行添加到 /etc/pacman.conf：
/etc/pacman.conf
[kde-unstable] Include = /etc/pacman.d/mirrorlist
kde-unstable 条目应位于仓库列表的顶部（即，位于启用的 core-testing 条目之上；见上方的警告）。
如果发现任何问题，请务必提交错误报告。
禁用测试版软件仓库
如果你启用了测试版仓库，但后来决定禁用它们，你应该：
- 从
/etc/pacman.conf中移除（注释掉）它们。 - 执行
pacman -Syuu以将更新从这些仓库“回滚”。
第二项是可选的，但如果发现任何问题，请记住这一点。
暂存 (Staging) 软件仓库
此仓库包含损坏的软件包，仅供开发人员在同时重新构建许多软件包期间使用。为了重新构建依赖于（例如新的共享库）的软件包，必须首先构建共享库本身并上传到暂存仓库，以便其他开发人员使用。一旦所有相关软件包都重新构建完毕，该软件包组就会根据情况移至测试版或主仓库。
有关更多历史细节，请参阅 引入暂存仓库的公告。
历史背景
大多数仓库的划分是出于历史原因。起初，当 Arch Linux 只有极少数用户使用时，只有一个名为 official 的仓库（现在的 core）。当时，official 基本上包含 Judd Vinet 偏好的应用程序。它旨在为每种“类型”的程序包含一个——一个桌面环境 (DE)，一个主要浏览器等。
当时有些用户不喜欢 Judd 的选择，既然 Arch 编译系统如此易于使用，他们就创建了自己的软件包。这些软件包进入了一个名为 unofficial 的仓库，并由 Judd 以外的开发者维护。最终，这两个仓库都被开发者视为获得同等支持，因此 official 和 unofficial 这两个名称不再反映其真实用途。随后在大约 0.5 版本发布时，它们被重命名为 current 和 extra。
在 2007.8.1 版本发布后不久，current 被重命名为 core，以避免对其包含的确切内容产生混淆。现在，在开发者和社区眼中，这些仓库或多或少是平等的，但 core 确实有一些区别。主要区别在于，用于安装光盘和发布快照的软件包仅取自 core。这个仓库仍然提供一个完整的 Linux 系统，尽管它可能不是你想要的那个 Linux 系统。
在 0.5/0.6 左右，有很多开发者不想维护的软件包。Jason Chu 建立了“受信任用户仓库 (Trusted User Repositories)”，这是受信任用户可以放置他们创建的软件包的非官方仓库。曾经有一个 staging 仓库，软件包可以通过 Arch Linux 开发者之一晋升到官方仓库，但除此之外，开发者和受信任用户或多或少是相互独立的。
这种模式运行了一段时间，但当受信任用户对他们的仓库感到厌倦，或者其他用户想要分享自己的软件包时，就不再适用了。这导致了 AUR 的开发。受信任用户 (Trusted Users) 组合成一个更紧密的群体，现在他们共同维护 community 仓库。TU 仍然是与 Arch Linux 开发者不同的群体，他们之间的交流并不多。然而，热门软件包偶尔仍会从 community 晋升到 extra。AUR 也允许所有用户提交 PKGBUILD。
在 core 中的一个内核导致许多用户系统损坏之后，引入了“core 验证政策 (core signoff policy)”。从那时起，core 的所有软件包更新都需要先经过 core-testing 仓库，并且只有在获得其他开发者或 Arch 测试团队成员的多次验证后，才允许移动。随着时间的推移，人们注意到各种 core 软件包的使用率较低，因此用户验证甚至没有错误报告也逐渐成为非正式接受此类软件包的标准。
在 2009 年底/2010 年初，随着一些新文件系统的出现以及在安装过程中支持它们的愿望，再加上意识到 core 从未被明确定义（只是“开发者亲手挑选的重要软件包”），该仓库得到了更准确的描述。
从 2021 年开始，并在 2023 年底最终完成，“受信任用户 (Trusted Users)”被重命名为“软件包维护者 (Package Maintainers)”。
2023 年，经过多年的前期工作，该发行版将其后端服务迁移到了 Git，并在此过程中切换到了新的仓库布局。在新的布局中，extra 将包含以前在 community 中的所有软件包，测试版仓库从 testing 拆分为 core-testing 和 extra-testing，community-testing 则被完全移除。从那时起，软件包维护者也能够向 extra 推送新软件包。