官方软件仓库
一个软件仓库是一个用于检索和安装软件包的存储位置。
Arch Linux 官方软件仓库包含必要的和流行的软件，可以通过 pacman 轻松访问。它们由软件包维护者维护。
官方软件仓库中的软件包会不断升级：当一个软件包升级后，它的旧版本会从仓库中移除。Arch 没有主要版本发布：每个软件包都会在上游发布新版本时进行升级。每个软件仓库始终保持一致性，即它托管的软件包始终具有相互兼容的版本。
稳定软件仓库
core
这个软件仓库可以在您最喜欢的镜像的 .../core/os/ 中找到。
core 包含用于以下用途的软件包
以及上述各项的依赖项（不一定是 makedepends）和 base 元软件包。
core 具有相当严格的质量要求。开发者/用户需要在软件包更新被接受之前签署认可。对于使用率较低的软件包，合理的曝光就足够了：通知人们关于更新，请求签署认可，根据变更的严重程度、缺少未解决的错误报告，以及软件包维护者的隐式签署认可，在 core-testing 中保留最多一周。
extra
这个软件仓库可以在您最喜欢的镜像的 .../extra/os/ 中找到。
extra 包含所有不适合放入 core 的软件包。这个软件仓库由 软件包维护者 和 Arch 开发者共同维护。示例：Xorg、窗口管理器、Web 浏览器、媒体播放器、用于处理 Python 和 Ruby 等语言的工具，以及更多。
multilib
这个软件仓库可以在您最喜欢的镜像的 .../multilib/os/ 中找到。
multilib 包含 32 位软件和库，可用于在 64 位安装上运行和构建 32 位应用程序（例如 wine、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
然后升级系统。
测试软件仓库
测试软件仓库的预期目的是为软件包提供一个暂存区，以便在被主软件仓库接受之前放置。软件包维护者（和普通用户）可以访问这些测试软件包，以确保新软件包的集成没有问题。一旦软件包经过测试且未发现错误，该软件包就可以移动到主软件仓库。
并非所有软件包都需要经过此测试过程。如果满足以下条件，新软件包将进入测试软件仓库
- 它们的目标是 core 软件仓库。core 中的所有内容都必须经过 core-testing。
- 预计它们在更新时会破坏某些东西，因此需要先进行测试。
- 它们影响许多软件包（例如 perl 或 python）。
测试软件仓库通常也用于大型软件包集合的新版本发布，例如 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
这个软件仓库包含最新 beta 或 Release Candidate 版本的 KDE Plasma 和 Applications。
要启用它，请将以下行添加到 /etc/pacman.conf
/etc/pacman.conf
[kde-unstable] Include = /etc/pacman.d/mirrorlist
kde-unstable 条目应位于软件仓库列表的顶部（即，在已启用的 core-testing 条目之上；请参阅上面的警告）。
如果您发现任何问题，请务必提交错误报告。
禁用测试软件仓库
如果您启用了测试软件仓库，但后来决定禁用它们，则应
- 从
/etc/pacman.conf中删除（注释掉）它们 - 执行
pacman -Syuu以“回滚”您从这些软件仓库进行的更新。
第二个项目是可选的，但如果您注意到任何问题，请记住它。
过渡软件仓库
这个软件仓库包含损坏的软件包，仅供开发人员在一次性重建许多软件包时使用。为了重建依赖于例如新的共享库的软件包，必须首先构建共享库本身并将其上传到过渡软件仓库，以便其他开发人员可以使用。一旦所有依赖软件包都重建完成，该软件包组就会被移动到测试或主软件仓库，以更合适的为准。
有关更多历史详情，请参阅 过渡软件仓库引入的公告。
历史背景
大多数软件仓库的拆分都是出于历史原因。最初，当 Arch Linux 的用户非常少时，只有一个软件仓库，称为官方（现在是 core）。当时，官方基本上包含了 Judd Vinet 偏好的应用程序。它的设计目的是包含每种“类型”的程序中的一个——一个 DE，一个主要的浏览器等。
当时有些用户不喜欢 Judd 的选择，因此由于 Arch 构建系统 非常易于使用，他们创建了自己的软件包。这些软件包进入了一个名为非官方的软件仓库，并由 Judd 以外的开发人员维护。最终，这两个软件仓库都被认为得到了开发人员的同等支持，因此 官方 和 非官方 的名称不再反映它们的真实目的。在 0.5 版本发布前后，它们随后被重命名为 current 和 extra。
在 2007.8.1 版本发布后不久，为了防止对它到底包含什么内容产生混淆，current 被重命名为 core。现在，在开发人员和社区眼中，这些软件仓库或多或少是平等的，但 core 确实有一些不同之处。主要的区别在于，用于安装 CD 和发布快照的软件包仅从 core 中获取。这个软件仓库仍然提供了一个完整的 Linux 系统，尽管它可能不是您想要的 Linux 系统。
大约在 0.5/0.6 版本左右，有很多软件包开发人员不想维护。Jason Chu 设置了“受信任用户软件仓库”，这些是非官方软件仓库，受信任用户可以在其中放置他们创建的软件包。有一个 staging 软件仓库，Arch Linux 开发人员之一可以将软件包提升到官方软件仓库中，但除此之外，开发人员和受信任用户或多或少是不同的。
这种情况持续了一段时间，但当受信任用户对他们的软件仓库感到厌倦时，以及当其他用户想要分享他们自己的软件包时，这种情况就行不通了。这导致了 AUR 的发展。受信任用户被合并成一个更紧密的群体，他们现在共同维护 community 软件仓库。TU 仍然是与 Arch Linux 开发人员分开的群体，他们之间没有太多沟通。但是，流行的软件包仍然偶尔从 community 晋升到 extra。AUR 还允许所有用户提交 PKGBUILD。
在 core 中的一个内核 破坏了许多用户系统 之后，引入了“core 签署认可政策”。从那时起，core 的所有软件包更新都需要先经过 core-testing 软件仓库，并且只有在获得其他开发人员或 Arch 测试团队 成员的多次签署认可后，才允许移动。随着时间的推移，人们注意到许多 core 软件包的使用率很低，用户签署认可甚至缺少错误报告也非正式地被接受为接受此类软件包的标准。
在 2009 年末/2010 年初，随着一些新文件系统的出现以及在安装过程中支持它们的愿望，以及意识到 core 从未明确定义（只是“重要的软件包，由开发人员精心挑选”），该软件仓库获得了更准确的描述。
从 2021 年开始，并在 2023 年末完成，“受信任用户”更名为“软件包维护者”。
2023 年，经过多年的前期工作，该发行版 将其后端服务迁移到 git，并在同一过程中也切换到了新的软件仓库布局。在新的布局中，extra 将包含以前在 community 中的所有软件包，测试软件仓库从 testing 分裂为 core-testing 和 extra-testing，community-testing 被完全删除。从那时起，软件包维护者也能够将新软件包推送到 extra。