官方倉庫

本頁使用了標題或全文手工轉換
出自 Arch Linux 中文维基

軟件倉庫是獲取軟件包的地方。

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

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

穩定倉庫[編輯 | 編輯原始碼]

core[編輯 | 編輯原始碼]

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

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

以及上述軟件包的依賴(不包括構建軟件包所需的依賴),以及 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窗口管理器網絡瀏覽器媒體播放器,程序語言支持PythonRuby等等。

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] 段落:

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

然後更新系統

testing 倉庫[編輯 | 編輯原始碼]

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

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

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

大的軟件集合,如GNOMEKDE 更新時會更新大批軟件包,也需要進行測試。

注意: testing 庫並不是「最新」軟件包的倉庫。它的目的是存放一些由於是[core]軟件集合的一部分或者由於其它方面的問題,可能引起系統崩潰的軟件包更新。我們強烈建議使用 testing 庫的用戶訂閱arch-dev-public郵件列表,監視testing 倉庫論壇,並報告bug。你也應該考慮加入Arch測試團隊
警告:
  • 謹慎啟用 core-testing 倉庫,其中的軟件包可能損壞系統。只有有足夠的經驗且知道如何應對問題的用戶才可以啟用。
  • 請同時啟用 core-testing 倉庫和 extra-testing 倉庫。如果啟用了下文的其他 testing 倉庫,也需要啟用 core-testingextra-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版本的時候,兩個倉庫更名為 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]倉庫軟件包更新前,必須先在一個叫做 core-testing 的倉庫進行測試,必須在其他開發者或 Arch Testing Team 成員同意後,軟件包才能正式移入 core 。後來, core 中出現一些低使用率的軟件,審核機制對它們有所寬鬆。

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

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