AUR 提交準則 - Arch Linux 中文维基

跳至內容

# AUR 提交準則

出自 Arch Linux 中文维基
翻譯狀態：

- 本文（或部分內容）譯自 AUR submission guidelines，最近一次同步於 2025-01-31，若英文版本有所更改，則您可以幫助同步與翻譯更改的內容。
- 您可以在 ArchWiki 的對應頁面找到本文翻譯的原始修訂歷史。
- 本文可能與英文原文存在出入。

相關文章

- Arch 打包準則
- 軟體包維護者指導原則

用戶可以通過 AUR 分享 PKGBUILD 腳本。AUR 中不包含任何二進制包，僅包含用戶上傳的 `PKGBUILD`，供其他用戶下載使用。這些 `PKGBUILD` 都是非官方的，沒有經過完整審查，使用風險自擔。

## 提交軟體包

警告：在提交前請先熟悉 Arch 打包準則及所有的「相關文章」。請仔細檢查上傳的內容是否有誤，違反相應規則的軟體包可能會不經警告被直接刪除。

如果在反覆閱讀該章節後仍不清楚軟體包或構建/提交流程是否正確，可以將自己的 `PKGBUILD` 貼到 AUR 郵件列表、論壇 AUR 版、中文論壇 AUR/ABS/PKGBUILD 版或 IRC 頻道，讓大家幫您檢查。

### 提交軟體包的規則

提交軟體包時請遵循下列的規則:

- 任何提交的 `PKGBUILD` 都不能編譯已經位於官方二進制軟體包倉庫的程序。可通過官方軟體包資料庫進行查找，如果在其中發現了任意版本的程序，就不要進行提交。如果認為官方倉庫的軟體包已過期，請標記它。如果它有問題或者缺少功能，請反饋反饋 bug 報告。

  唯一的例外是和官方打包版本相比增加或開啟了新的功能或者使用了不同的補丁。這時需要修改 `pkgname` 來表示新增的功能。例如加入了邊欄支持的 GNU screen（`screen`）應該命名為 `screen-sidebar`。此外還需要同時添加 `conflicts=('screen')` 以避免與官方倉庫中的包衝突。

- 檢查 AUR 中是否已有相同軟體包。如果已經有人維護某軟體包，可以以評論的形式將更改報告給維護人員。如果軟體包無人維護或維護者無反饋，可以按需將其認領並更新。不要創建重複的包。

- 確保您的軟體包有人需要。在提交前請仔細想想：有人會用這個軟體包嗎？它非常特別嗎？如果不是只有少數人覺得它有用，就提交它。

  AUR 和官方軟體倉庫是用於放置通用軟體和軟體相關的內容的，包括：可執行文件、配置文件、軟體的在線/離線文檔和軟體直接使用的媒體數據。

- 不支持 `x86_64` 架構的軟體包不允許上傳到 AUR。

- 不要在 AUR `PKGBUILD` 中使用 `replaces`，除非這個軟體包將要被重命名（例如當 Ethereal 變成 Wireshark 時）。如果這個軟體包是已經存在的軟體包的另一版本，使用 `conflicts` （或者如果這個軟體包被其他軟體需要時，使用 `provides`）。兩者的主要區別是：在 pacman 同步（-Sy）之後，如果遇到與 `replaces` 匹配並已經安裝的軟體包時，pacman 會立刻想去替換它。而 `conflicts` 則在安裝軟體包時進行替換。

- 請為那些由版本控制系統構建，而不屬於任何特定版本的軟體包的包名添加合適的後綴，如 `-git`。具體細則見 VCS 軟體打包準則#軟體包命名。

- 當源碼可獲得時，那些預構建可以直接部署的二進制包應該加上 `-bin` 後綴， Java 除外。除此之外，AUR 不應當包含 `makepkg` 創建的二進制包，也不應當包含文件列表。

- 從特定版本的源碼構建的包不應該添加後綴。

- 請按照以下格式在 `PKGBUILD` 最上端加入包含當前維護者和過去的貢獻者的信息注釋，記得對郵件地址進行必要的處理以避免被垃圾郵件騷擾。然後移除所有不必要的行。例如：

注意：對郵件地址進行混淆會導致別人更難聯繫上你。

  如果您從其它人接手了一個 `PKGBUILD`，像這樣把您的名字和郵件地址加到最上面。

      # Maintainer: Your Name <address at domain dot tld>

  如果在您之前有其他的維護者，請將它們添加到貢獻者中。如果你不是初始上傳者，也請將其加入貢獻者中。如果您是協同維護者，也請加上現在的其他維護者。

      # Maintainer: Your name <address at domain dot tld>
      # Maintainer: Other maintainer's name <address at domain dot tld>
      # Contributor: Previous maintainer's name <address at domain dot tld>
      # Contributor: Original submitter's name <address at domain dot tld>

- 為倉庫添加 `LICENSE` 文件，建議使用 0BSD 許可證。你可以直接從 RFC 0040 複製許可證文本。缺少許可證或使用與 0BSD 不同許可證的軟體包不允許被加入到官方軟體源中。

### 認證

要向 AUR 寫入軟體包，用戶需要創建一個 SSH 密鑰。將公鑰導入到用戶帳戶的 My Account 一節，然後為 `aur.archlinux.org` 主機配置對應的私鑰，例如：

    ~/.ssh/config

    Host aur.archlinux.org
      IdentityFile ~/.ssh/aur
      User aur

你應當為 AUR 生成新的密鑰，而不是直接使用舊的，以在出問題時直接棄用密鑰：

    $ ssh-keygen -f ~/.ssh/aur

提示：在輸入公鑰時可以通過換行的方式設置添加多個公鑰。

### 創建軟體包倉庫

如果您正在創建新的軟體包，請通過克隆所需的 pkgbase 的方式建立一個遠程 AUR 倉庫和本地 Git 倉庫。如果軟體包還不存在，則會出現以下預料之中的警告：

    $ git -c init.defaultBranch=master clone ssh://aur@aur.archlinux.org/pkgbase.git

    Cloning into 'pkgbase'...
    warning: You appear to have cloned an empty repository.
    Checking connectivity... done.

注意：如果 `pkgbase` 與被刪除的軟體包相同，那克隆下來的倉庫會不為空。

如果您已經有一個軟體包了，但不是 Git 倉庫的話，需要進行初始化：

    $ git -c init.defaultBranch=master init

並添加遠程 AUR 地址：

    $ git remote add label ssh://aur@aur.archlinux.org/pkgbase.git

然後向遠程倉庫拉取以在 AUR 進行初始化。

提示：使用拉取和變基來解決 `pkgbase` 匹配到已刪除軟體包的衝突問題。

### 提交和更新軟體包

警告：不想以全局身份提交？記得通過 `git config user.name [...]` 和 `git config user.email [...]` 編輯自己的本地身份！
警告：你的提交會以全局 Git 名稱和郵件地址進行署名，且在推送後很難對提交進行修改（FS#45425）。如果你想以不同的身份推送到 AUR，可以使用 `git config user.name "..."` 和 `git config user.email "..."` 對單個包進行修改。

當釋出新版本的軟體時，更新 pkgver 或者 pkgrel 變量來提示所有的用戶更新。如果僅僅是對 PKGBUILD 的小修改（例如修正筆誤），請不要更新這些變量。

不要僅僅為了更新 `pkgver` 就更新 VCS 軟體包。當上游有新的提交時，他們不會被視為過時。只有當有其他變化，比如打包流程發生變化時，才應該進行更新。

無論何時 `PKGBUILD` 的元數據發生變動（例如更新了 `pkgver()`），都需要重新生成 .SRCINFO。否則 AUR 不會顯示更新後的版本號。

要上傳或者更新一個軟體包，至少要添加 `PKGBUILD` 和 `.SRCINFO` 和其它所有新增的或者修改過的輔助文件（例如 .install 文件或者如軟體包補丁之類的本地源碼文件），寫上有意義的提交信息並提交，最後推送這些變動到 AUR 上。

例如:

    $ makepkg --printsrcinfo > .SRCINFO
    $ git add PKGBUILD .SRCINFO
    $ git commit -m "useful commit message"
    $ git push

注意：

- 如果您忘記在最後一次提交中包含 `.SRCINFO`，您可以通過 `git commit --amend` 修改最後一次提交來使得 AUR 接受您的推送。
- AUR 只允許推送到 `master` 分支。如果本地分支的名稱不同，需要將其重命名後再次推送。

提示：為了保持工作目錄和提交儘可能的乾淨，可以創建 gitignore(5) 文件來排除所有文件，然後再按需添加文件。

## 維護軟體包

- 閱讀其他用戶的反饋，並試著聽從建議改進軟體包，這是個學習的過程！
- 升級軟體包後，不要在評論中加入版本更新信息，這些信息會沖淡更重要的用戶評論。
- 不要提交軟體包後就放任不管！檢查更新並改進 `PKGBUILD` 是維護者的責任。
- 發覺自己不再想維護某個軟體包？可以通過 AUR 網頁界面 `disown` 一個軟體包並/或是在 AUR 郵件列表發條消息。如果這個包的所有維護者都 disown，那麼它就會變成一個「orphaned」軟體包。
- 自動化對維護人員來說很有用，但它不能取代人工干預（例如：項目可能會修改許可證、添加或刪除依賴關係，以及其它的顯著更改）。自動更新 `PKGBUILD` 的風險將由您自行承擔，任何出現問題的帳戶與他們提交的軟體包都可能被無事前通知地刪除。

## 請求

刪除、合併、取消維護權限請求可以通過右側「Package actions」的「File Request」連結執行。這會給當前的維護者和 aur-requests 郵件列表自動發送郵件通知，之後軟體包維護者會接受或拒絕請求。

### 刪除

你可以請求 unlist AUR 中的一個 `pkgbase`。提交時請附上原因說明（務必用英語），也可以是其它有用的細節（比方說其它包提供了相同的東西，或者如果你就是這個包的維護者，需要重命名且軟體包所有者同意，等等）。

注意：

- 只在軟體包的評論區解釋原因並不夠。當軟體包維護者採取行動前，aur-request 郵件列表是唯一能取得這些信息的地方。
- 刪除請求可能被否決。如果你是這個包的維護者，我們可能會建議你 disown 這個軟體包，以便其他維護者認領。
- 在軟體包被「刪除」後，其 Git 倉庫仍可被克隆。

### 合併

合併請求會刪除 `pkgbase`，並將現有的投票數、評論轉移到另一個 `pkgbase` 中。需要用到目標軟體包的名稱。

這個操作適用於上游進行了重命名項目等情況。

注意：

- 這和 `git merge` 或者 GitLab 的 merge request 沒有任何關係。
- 由於投票和評論會轉移到已經存在的目標中，如果一個包本身沒有投票或評論，那麼其效果與#刪除並連結到新包完全相同。

### 撤銷所有權（orphan）

要求撤銷當前維護者對 `pkgbase` 的所有權。如果現有維護者在兩周之內沒有響應，請求就會通過。另外，如果一個軟體被標記為過期超過 180 天，請求會被自動通過。

分類：​

- 關於 Arch
- 包開發
- 包管理

AUR 提交準則
新增話題