Official repositories (简体中文)

From ArchWiki
Jump to navigation Jump to search

软件仓库是获取软件包的地方。

Arch Linux 官方软件仓库 包含着基础的和较为流行的软件。他们可通过Pacman便捷的获取。软件包由软件包维护者维护

官方软件仓库中的软件包会持续更新:老版本将被新版本所替代。Arch 没有主版本的概念:每个软件在上游有新版本时单独更新。每一个软件仓库都是互相联系的,即,软件仓库中的所有软件都是相互兼容的。

稳定仓库

core

core 仓库位于您最喜欢的仓库镜像.../core/os/ 目录。

core仓库包含着用于以下用途的软件包:

以及上述软件包的依赖(不包括构建软件包所需的依赖),以及 base 元软件包

core 仓库对包有着相当严格的质量要求。软件包的更新需要经过开发者和用户的审察批准。对于低使用率的软件,适当的审核足矣:发布关于更新的通知,请求审核,根据更新的重要性在 #testing 仓库暂留至多一周,并在确保无未解决bug报告后,由软件包维护者审核通过。

提示: 如需在没有网络连接的情况下从 core (或其他软件仓库)创建本地软件仓库,见 Pacman/Tips and tricks#Installing packages from a CD/DVD or USB stick

extra

extra 仓库位于您最喜欢的仓库镜像的 .../extra/os/ 目录。

extra包含不适合在core仓库的所有软件包,比如:Xorg窗口管理器网络浏览器媒体播放器,程序语言支持,如PythonRuby等等。

community

community 仓库位于您最喜欢的仓库镜像的 .../community/os/ 目录。

community 仓库包含由受信用户(TU)接管、获得足够多打分的AUR软件包。该仓库中的某些软件包还可能收录进 coreextra 仓库。

multilib

multilib 仓库位于您最喜欢的仓库镜像的 .../multilib/os/ 目录。

multilib 包含着32位的软件和链接库,可以用于在64位系统上运行和构建32位软件,例如 wine steam 等。

启用multilib

想使用 multilib 仓库,请在/etc/pacman.conf文件中取消 [multilib] 段落的注释:

/etc/pacman.conf
[multilib]
Include = /etc/pacman.d/mirrorlist

然后更新系统

提示: 运行 pacman -Sl multilib 来列出在multilib仓库里的所有软件包,32位链接库的软件包以 lib32- 开头

禁用multilib

运行下面命令可以删除所有从 multilib 安装的软件:

# pacman -R $(comm -12 <(pacman -Qq | sort) <(pacman -Slq multilib | sort))

如果有 gcc-libs 冲突,请重新安装 gcc-libsbase-devel软件包组:

/etc/pacman.conf 中注释掉 [multilib] 段落:

#[multilib]
#Include = /etc/pacman.d/mirrorlist
/etc/pacman.conf
#[multilib]
#Include = /etc/pacman.d/mirrorlist

然后更新系统

testing 仓库

testing 仓库的目的是提供一个即将被放入主软件仓库的软件包的集散地。软件包维护者(和普通用户)可以访问并测试这些软件包以确保软件包没有问题。当位于 testing 仓库的软件包被测试无问题后,即可被移入主仓库。

不是所有的包都需要经过如此的测试过程,但是所有的将移入 core 仓库的软件包都必须先经过 testing 仓库。会影响到大量其他软件的软件包(例如 perl 或者 python)也必须经过测试。大的软件包组,如GNOMEKDE,也需要进行测试。

警告:
  • 谨慎启用 testing 仓库,其中的软件包可能损坏系统。只有有足够的经验且知道如何应对问题的用户才可以启用。
  • 如果你启用 testing 仓库,你一定要同时启用 community-testing 仓库。如果你启用了下文的其他 testing 仓库,也需要启用 testingcommunity-testing 仓库

testing

testing 仓库位于您最喜欢的仓库镜像的 ../testing/os/ 目录中。

testing 包含即将进入 core extra 软件库的候选软件包。

下列软件包会进入 testing 库:

  • 需要进入 core 仓库的软件包。一切需要进入 core 仓库的软件包都需要先经过 testing 仓库
  • 更新该软件包可能损坏系统,需要进行测试。

testing 库是唯一可能和其它官方软件仓库有软件包名称冲突的仓库。如果要启用,应该在 pacman.conf 文件里把它设置为第一个仓库。

testing 库并不是“最新”软件包的仓库。它的目的是存放一些由于是[core]软件集合的一部分或者由于其它方面的问题,可能引起系统崩溃的软件包更新。我们强烈建议使用 testing 库的用户订阅arch-dev-public邮件列表,监视testing 仓库论坛,并报告bug。你也应该考虑加入Arch测试团队

community-testing

community-testing库的功能类似 testing ,不过是为 community 库设计的测试仓库。

multilib-testing

multilib-testing 库的功能类似 testing ,不过是为 multilib-testing 库设计的测试仓库。

gnome-unstable

GNOME 桌面环境的下一个稳定版本,在进入主 testing 仓库前,会先放到 gnome-unstable.

要启用它,在 /etc/pacman.conf 中加入:

[gnome-unstable]
Include = /etc/pacman.d/mirrorlist

gnome-unstable 项需要在所有仓库的最上面(保证在 testing 上面).

如果有软件包相关的问题,请在 Arch bug tracker 汇报,其它问题请 上游的 GNOME Gitlab汇报。

kde-unstable

包含 KDE Plasma 和应用程序的 beta候选发行版本.

要启用它,将下面内容加入 /etc/pacman.conf:

[kde-unstable]
Include = /etc/pacman.d/mirrorlist

kde-unstable 项需要在所有仓库的最上面(保证在 testing 上面).

报告 遇到的问题。

禁用测试仓库

如果要禁用之前启用的测试仓库,应该:

  1. /etc/pacman.conf 中删除(注释)掉配置
  2. 执行 pacman -Syuu 将从这些仓库安装的软件还原到主仓库版本。

第二条为可选操作,如果在第一步后碰到任何问题,请先执行此操作。

staging repositories

警告: 不要因为任何原因启用 staging 仓库,因为你的系统一定会在更新后损坏。这个仓库仅为后端开发人员使用

该存储库包含损坏的包,并且在一次重建多个包时仅供开发人员使用。 例如,为了重建依赖于新共享库的包,必须首先构建共享库本身并将其上传到临时存储库,以便其他开发人员可以使用。 一旦所有依赖包都被重建,这组包就会被转移到测试或主存储库,以更合适的方式.

详情请见 l[失效链接 2021-11-15 ⓘ]

历史背景

大部分仓库是因为历史原因分开的。原本,当这个发行版只有一小部分用户时,是只有一个软件仓库的,它就是现在的 core ──那时候它叫做 official 。这个仓库主要存放了Judd Vinet选定的应用程序,当然现在已经不是这样了:它被设计为只包含“每种类型”程序中的一个 ── 一个桌面环境、一个主浏览器等等。

后来有用户不满Judd的选择,由于ABS系统使用简单,所以他们就用ABS来创建自己的软件包。这些软件包被放入一个名为unofficial的软件仓库,而这个仓库由除Judd以外的开发人员维护。最终,新仓库获得开发人员同样的支持,所以就不再使用 official 和 unofficial 这两个名称了。大约在0.5版本的时候,两个仓库更名为 currentextra

在2007.8.1版本发布之后, current 更名为 core ,以免让人误解它包含的内容。如今,这两个仓库在开发人员和社区眼中都是相同分量的。不过 core 还是有些不同的,主要区别在于安装光盘和发布的快照中的软件包都只在 core 当中。这个仓库可以实现一个完整的Linux系统,但并不一定是你想要的Linux系统。

在0.5或者0.6版本的时候,仓库里有大量的软件包没有开发者愿意去维护。于是一位开发人员(Xentac)建立了“受信用户仓库”(Trusted User Repositories),作为存放被信任的用户(TU)自行创建的软件包的仓库。staging仓库里的软件包可以被Arch Linux的开发人员选拔入官方仓库,不过除此之外,开发人员和受信用户或多或少还是有所不同的。

就这样过了一段时间,逐渐的受信用户对他们的软件仓库感到厌倦,而非受信用户又期望可以将自己的软件包与大家分享。这导致了AUR的出现。慢慢的TU们形成更为严密的组织,如今他们共同维护community软件仓库。TU是一个独立于Arch Linux开发人员之外的组织,两者并没太多交流。不过,热门的软件包仍然会偶尔从 community 选拔入 extraAUR也允许非受信用户提交PKGBUILD给其他用户自愿使用。

在2006年,core仓库里未被正确编译的内核导致许多用户系统崩溃。之后,“core仓库审核机制”引入:所有[core]仓库软件包更新前,必须先在一个叫做 testing 的仓库进行测试,必须在其他开发者同意后,软件包才能正式移入 core 。后来, core 中出现一些低使用率的软件,审核机制对它们有所宽松。

2009年末至2010年初,出现了一些新的文件系统,人们希望在安装系统时就使用它们(即纳入 core )。鉴于 core 从来没有给出明确的界定(只是重要的包,由开发者亲自挑选的)它有了一个更为明确的定义。