Official repositories (简体中文)

From ArchWiki
(Redirected from 官方软件仓库)
Jump to navigation Jump to search

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

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

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

稳定仓库

core

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

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

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

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

Tip: 如需在没有网络连接的情况下从 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 仓库,因为你的系统一定会在更新后损坏。这个仓库仅为后端开发人员使用

This repository contains broken packages and is used solely by developers during rebuilds of many packages at once. In order to rebuild packages that depend on, for example, a new shared library, the shared library itself must first be built and uploaded to the staging repositories to be made available to other developers. As soon as all dependent packages are rebuilt, the group of packages is then moved to testing or to the main repositories, whichever is more appropriate.

详情请见 l

历史背景

大部分仓库是因为历史原因分开的。原本,当这个发行版只有一小部分用户时,是只有一个软件仓库的,它就是现在的 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 从来没有给出明确的界定(只是重要的包,由开发者亲自挑选的)它有了一个更为明确的定义。