官方倉庫

翻譯狀態：

• 本文（或部分內容）是 Official repositories 的翻譯，最近一次同步的日期是 2023-05-23，如果英文版本有所更改，則您可以幫助同步翻譯更改的內容。
• 您可以在ArchWiki 的對應頁面找到本文翻譯的原始編輯記錄和貢獻者列表。

相關文章

• Arch 用户軟件庫 (AUR)
• Arch 組建系統
• makepkg
• Mirrors
• 官方倉庫 web 介面
• pacman
• PKGBUILD
• 非官方用户倉庫

軟件庫是取得軟件包的地方。

Arch Linux 官方軟件庫 包含着基礎的和較為流行的軟件。他們可通過Pacman便捷的取得。軟件包由軟件包維護者維護。

官方軟件庫中的軟件包會持續更新，即老版本將被新版本所替代。Arch 沒有主版本的概念：每個軟件在上游有新版本時單獨更新。每一個軟件庫都是互相聯繫的，即，軟件庫中的所有軟件都是相互相容的。

穩定倉庫

core

core 倉庫位於倉庫鏡像的 .../core/os/ 目錄。

core倉庫包含着用於以下用途的軟件包:

• 啟動 Arch 系統。
• 連接網絡
• 建立軟件包
• 檢查、管理和修復所支援的檔案系統
• 系統安裝（例如openssh^包）。

以及上述軟件包的依賴（不包括組建軟件包所需的依賴），以及 base^包 元軟件包。

core 倉庫對包有着相當嚴格的質素要求。軟件包的更新需要經過開發者和用户的審察批准。對於低使用率的軟件，適當的審核足矣：發佈關於更新的通知，請求審核，根據更新的重要性在 core-testing 倉庫暫留至多一周，並在確保無未解決bug報吿後，由軟件包維護者審核通過。

提示：如需在沒有網絡連接的情況下從 core （或其他軟件庫）建立本地軟件庫，見 Pacman/Tips and tricks#Installing packages from a CD/DVD or USB stick

extra

extra 倉庫位於您最喜歡的倉庫鏡像的 .../extra/os/ 目錄。

extra包含不適合在core倉庫的所有軟件包，由 Trusted Users 和 Arch 開發者共同維護。 比如：Xorg，視窗管理員，網絡瀏覽器，媒體播放器，程式語言支援Python和Ruby等等。

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-libs^包和base-devel^包的依賴：

在 /etc/pacman.conf 中註釋掉 [multilib] 段落：

/etc/pacman.conf

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

然後更新系統

testing 倉庫

testing 倉庫的目的是提供一個即將被放入主軟件庫的軟件包的集散地。軟件包維護者（和普通用户）可以訪問並測試這些軟件包以確保軟件包沒有問題。當位於 testing 倉庫的軟件包被測試無問題後，即可被移入主倉庫。

不是所有的包都需要經過如此的測試過程，滿足如下條件的軟件包會進測試倉庫：

• 一切需要進入 core 倉庫的軟件包都需要先經過 core-testing 倉庫
• 更新該軟件包可能損壞系統，需要進行測試。
• 會影響到大量其它的軟件包，例如 perl^包 或者 python^包。

大的軟件集合，如GNOME 或 KDE 更新時會更新大批軟件包，也需要進行測試。

注意： testing 庫並不是「最新」軟件包的倉庫。它的目的是存放一些由於是[core]軟件集合的一部分或者由於其它方面的問題，可能引起系統崩潰的軟件包更新。我們強烈建議使用 testing 庫的用户訂閱arch-dev-public郵寄清單，監視testing 倉庫論壇，並報吿bug。你也應該考慮加入Arch測試團隊

警吿：

• 謹慎啟用 core-testing 倉庫，其中的軟件包可能損壞系統。只有有足夠的經驗且知道如何應對問題的用户才可以啟用。
• 請同時啟用 core-testing 倉庫和 extra-testing 倉庫。如果啟用了下文的其他 testing 倉庫，也需要啟用 core-testing 和 extra-testing 倉庫
• 由於並不是所有的主倉庫軟件包都在測試倉庫中有相應的版本，core 和 extra 主倉庫應該保留，並保證相應的測試倉庫在主倉庫的前面

core-testing

位於鏡像的 .../core-testing/os/ 目錄。

core-testing 包含要進入 core 倉庫的候選軟件包。

core-testing 庫是唯一可以與其它官方軟件庫有名稱衝突的倉庫。如果要啟用，應該在 pacman.conf 檔案裡把它設定為第一個倉庫。

extra-testing

extra-testing庫的功能類似 core-testing ，不過是為 extra 庫服務的測試倉庫。

multilib-testing

multilib-testing 庫的功能類似 testing ,不過是為 multilib-testing 庫服務的測試倉庫。

gnome-unstable

GNOME 桌面環境的下一個穩定版本，在進入主 extra-testing 倉庫前，會先放到 gnome-unstable.

要啟用它，在 /etc/pacman.conf 中加入:

/etc/pacman.conf

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

gnome-unstable 項需要在所有倉庫的最上面（保證在 core-testing 上面），即：

/etc/pacman.conf

[gnome-unstable]
[core-testing]
[core]
[extra-testing]
[extra]

如果有軟件包相關的問題，請在 Arch bug tracker 匯報，其它問題請 上游的 GNOME Gitlab匯報。

kde-unstable

包含 KDE Plasma 和應用程式的 beta 或 候選發行版本.

要啟用它，將下面內容加入 /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 repositories

警吿： 不要因為任何原因啟用 staging 倉庫，因為你的系統一定會在更新後損壞。這個倉庫僅為後端開發人員使用

該存放庫包含損壞的包，並且在一次重建多個包時僅供開發人員使用。 例如，為了重建依賴於新共享庫的包，必須首先組建共享庫本身並將其上載到臨時存放庫，以便其他開發人員可以使用。 一旦所有依賴包都被重建，這組包就會被轉移到測試或主存放庫，以更合適的方式.

詳情請見 staging 倉庫發佈通知。

歷史背景

大部分倉庫是因為歷史原因分開的。原本，當這個發行版只有一小部分用户時，是只有一個軟件庫的，它就是現在的 core ──那時候它叫做 official 。這個倉庫主要存放了Judd Vinet選定的應用程式，當然現在已經不是這樣了：它被設計為只包含「每種類型」程式中的一個 ── 一個桌面環境、一個主瀏覽器等等。

後來有用户不滿Judd的選擇，由於ABS系統使用簡單，所以他們就用ABS來建立自己的軟件包。這些軟件包被放入一個名為unofficial的軟件庫，而這個倉庫由除Judd以外的開發人員維護。最終，新倉庫獲得開發人員同樣的支援，所以就不再使用 official 和 unofficial 這兩個名稱了。大約在0.5版本的時候，兩個倉庫更名為 current 和 extra 。

在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 選拔入 extra 。AUR也允許非受信用户提交PKGBUILD給其他用户自願使用。

在2006年，core倉庫裡未被正確編譯的內核導致許多用户系統崩潰。之後，「core倉庫審核機制」引入：所有[core]倉庫軟件包更新前，必須先在一個叫做 core-testing 的倉庫進行測試，必須在其他開發者或 Arch Testing Team 成員同意後，軟件包才能正式移入 core 。後來， core 中出現一些低使用率的軟件，審核機制對它們有所寬鬆。

2009年末至2010年初，出現了一些新的檔案系統，人們希望在安裝系統時就使用它們（即納入 core ）。鑑於 core 從來沒有給出明確的界定（只是重要的包，由開發者親自挑選的）它有了一個更為明確的定義。

2023 年，經過幾年的準備工作，Arch 將後端服務遷移到了 git，並同時啟用了新的倉庫佈局。在新的佈局中，extra 包含了之前 community 倉庫的軟件包，testing 倉庫分成了 core-testing 和 extra-testing, community-testing 被刪除。 Trusted Users 也有了推送軟件包到 extra 的權限。