官方软件仓库

来自 ArchWiki
(重定向自 Extra repository)

相关条目

软件仓库 是一个存储位置，从中检索软件包以进行安装。

Arch Linux **官方软件仓库** 包含必要的和流行的软件，可以通过 pacman 轻松访问。 它们由 软件包维护者 维护。

官方软件仓库中的软件包会不断升级：当软件包升级时，其旧版本将从仓库中删除。 Arch 没有主要版本发布：每个软件包都会在上游来源提供新版本时进行升级。 每个仓库始终是连贯的，即它托管的软件包始终具有相互兼容的版本。

稳定软件仓库

core

此仓库可以在您喜欢的 镜像 的 `.../core/os/` 中找到。

core 包含以下软件包：

以及上述项的依赖项（不一定是 makedepends）和 base 元软件包。

core 具有相当严格的质量要求。 开发人员/用户需要在软件包更新被接受之前对更新进行签名确认。 对于使用率低的软件包，合理的曝光就足够了：通知人们有关更新，请求签名确认，根据更改的严重程度，在 core-testing 中保留长达一周的时间，没有未解决的错误报告，以及软件包维护者的隐式签名确认。

提示： 要在没有互联网连接的情况下，使用来自 core（或其他仓库）的软件包创建本地仓库，请参阅 Pacman tips#从 CD/DVD 或 USB 存储棒安装软件包

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/Tips and tricks#软件包的依赖项）。

注意： 如果命令返回 `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 软件包集的一部分，还是以其他方式至关重要。 因此，强烈建议测试仓库的用户订阅 arch-dev-public 邮件列表，关注 测试仓库论坛，并 报告所有错误。 您还应该考虑加入 Arch 测试团队。
警告
  • 测试仓库可能包含预发布软件版本。
  • 启用测试仓库时请小心。 执行更新后，您的系统可能会崩溃。 只有知道如何处理潜在系统崩溃的经验丰富的用户才应使用它。
  • 如果您启用 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 条目之上；请参阅上面的警告）。

如果您发现任何问题，请确保 提交错误报告。

禁用测试软件仓库

如果您启用了测试仓库，但后来决定禁用它们，则应：

  1. 从 `/etc/pacman.conf` 中删除（注释掉）它们。
  2. 执行 `pacman -Syuu` 以“回滚”您从这些仓库进行的更新。

第二项是可选的，但如果您注意到任何问题，请记住它。

过渡软件仓库

警告： 无论出于何种原因，都不要启用 staging 仓库。 执行更新后，您的系统肯定会崩溃。 此仓库仅供后端开发人员使用。

此仓库包含损坏的软件包，仅供开发人员在一次重建多个软件包时使用。 为了重建依赖于例如新共享库的软件包，必须首先构建共享库本身并将其上传到过渡仓库，以便其他开发人员可以使用。 一旦所有依赖软件包都重建完成，软件包组就会被移动到测试仓库或主仓库，以更合适的为准。

有关更多历史详细信息，请参阅 过渡仓库引入的公告。

历史背景

大多数仓库拆分都是出于历史原因。 最初，当 Arch Linux 的用户非常少时，只有一个仓库被称为**官方**（现在是 core）。 当时，official 基本上包含 Judd Vinet 首选的应用程序。 它旨在包含每种“类型”的程序之一 — 一个 DE，一个主要浏览器等。

当时有些用户不喜欢 Judd 的选择，因此由于 Arch 构建系统 非常易于使用，他们创建了自己的软件包。 这些软件包进入了一个名为 **unofficial** 的仓库，并由 Judd 以外的开发人员维护。 最终，这两个仓库都被认为同样受到开发人员的支持，因此名称 official 和 unofficial 不再反映它们的真实目的。 在大约 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-testing 仓库，并且只有在获得其他开发人员或 Arch 测试团队 成员的多次签名确认后才能移动。 随着时间的推移，人们注意到各种 core 软件包的使用率很低，用户签名确认甚至缺乏错误报告也被非正式地接受为接受此类软件包的标准。

在 2009 年末/2010 年初，随着一些新文件系统的出现以及在安装过程中支持它们的愿望，以及认识到 core 从未明确定义（只是“开发人员精心挑选的重要软件包”），该仓库获得了更准确的描述。

此条目或章节需要扩充。

原因： 2010 年至 2023 年的历史缺失：应该记录从“受信任用户仍然是与 Arch Linux 开发人员分开的群体，他们之间没有太多沟通”到将他们视为发行版的完整组成部分的过程。 （在 Talk:Official repositories 中讨论）

从 2021 年开始，并在 2023 年底最终确定，“受信任用户”被重命名为“软件包维护者”。

2023 年，经过多年的前期工作，发行版 将其后端服务迁移到 git，并在同一过程中也切换到了新的仓库布局。 在新的布局中，extra 将包含以前在 community 中的所有软件包，并且测试仓库从 testing 拆分为 core-testing 和 extra-testing，community-testing 已完全删除。 从那时起，软件包维护者 也能够将新软件包推送到 extra。

取自“https://wiki.archlinux.org.cn/index.php?title=Official_repositories&oldid=824573#extra”