官方倉庫

本頁使用了標題或全文手工轉換
出自 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 的權限。