AUR 提交準則

出自 Arch Linux 中文维基

用戶可以通過 Arch User Repository 分享 PKGBUILD。AUR 中不包含任何二進位包,僅包含用戶上傳的 PKGBUILD,供其他用戶下載使用。所有軟體包都是非官方的,使用風險自擔。

提交軟體包[編輯 | 編輯原始碼]

警告: 在提交前請先熟悉 Arch packaging standards 及所有的"相關文章"。違反相應規則的軟體包可能不經警告被直接刪除。

如果對自己的 PKGBUILD 缺乏信心,可以先把它貼到AUR 郵件列表論壇 AUR 版IRC 頻道,讓大家幫您檢查。

提交軟體包的規則[編輯 | 編輯原始碼]

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

  • 仔細檢查上傳的文件。編寫PKGBUILD前務必閱讀 Arch軟體打包標準。劣質的 PKGBUILD 會影響軟體的正常使用,不要指望別人會因為您糟糕的 PKGBUILD 浪費了他們的時間而收到感謝。
  • 任何提交的 PKGBUILD 都不能編譯已經位於官方二進位軟體包倉庫的程序。如果認為官方倉庫的軟體包已過期,請標記它。如果它有問題或者缺少功能,請反饋 bug 報告
唯一的例外是和官方打包版本相比增加或開啟了新的功能或者使用了不同的補丁。這時需要修改 pkgname 來表示新增的功能。例如加入了邊欄支持的 screen 應該命名為 screen-sidebar。此外還需要同時添加 provides=('screen') 以避免與官方倉庫中的包衝突。
  • 檢查 AUR 中是否已有相同軟體包。如果已經有人維護某軟體包,可以以評論的形式將變化報告給維護人員。如果軟體包無人維護或不存在,用戶提交的軟體包將被認領。別創建重複的包。
  • 確保您的軟體包有人需要,有人會用這個軟體包嗎?它非常特別嗎?如果有一些人覺得它有用,就提交它。
AUR 和官方軟體倉庫中計劃放置通用軟體和軟體相關的內容,包括:可執行文件、配置文件、軟體的在線/離線文檔和軟體直接使用的媒體數據。
  • 不要在 AUR PKGBUILD 中使用 replaces,除非這個軟體包將要被重命名(例如當 Ethereal 變成 Wireshark 時)。如果這個軟體包是已經存在的軟體包的另一版本,使用 conflicts (或者如果這個軟體包被其他軟體需要時,使用 provides)。兩者的主要區別是:在 pacman 同步(-Sy)之後,如果遇到與 replaces 匹配並已經安裝的軟體包時,pacman 會立刻想去替換它。而 conflicts 則在安裝軟體包時進行替換。
  • 如果原始碼是可取得的,請避免提交二進位文件。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>

認證[編輯 | 編輯原始碼]

要向 AUR 寫入軟體包,用戶需要創建一個 SSH key 。將公鑰導入到用戶帳戶的我的帳號一節,然後為 aur.archlinux.org 指定私鑰的位置,例如:

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

建議為 AUR 創建一個新的密鑰(而不是用舊的),這樣出問題時可以直接廢除密鑰:

$ ssh-keygen -f ~/.ssh/aur
提示:在輸入公鑰時可以通過換行的方式設置添加多個公鑰。

創建軟體包倉庫[編輯 | 編輯原始碼]

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

$ git clone ssh://aur@aur.archlinux.org/pkgbase.git
Cloning into 'pkgbase'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.
注意: 即使 AUR 中的軟體包被刪除 Git 倉庫也不會刪除,所以您可能會發現 clone 一個 AUR 中還不存在的軟體包時不會看到這個警告。

如果您已經有一個軟體包了,如果它不是 Git 倉庫的話,初始化並添加遠程 AUR 地址:

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

然後從遠程獲取文件並初始化。

提示:使用推送和變基來解決 pkgbase 匹配到已刪除軟體包的衝突問題。

提交和更新軟體包[編輯 | 編輯原始碼]

警告: 不想以全局身份提交?記得通過 git config user.name [...]git config user.email [...] 編輯自己的本地身份!

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

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

要上傳或者更新一個軟體包,至少添加 PKGBUILD.SRCINFO 和其他所有新增的或者修改過的輔助文件(例如 .install 文件或者如補丁之類的本地源碼文件),提交,最後推送這些變動到AUR上。

例如:

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "useful commit message"
$ git push
注意: 如果您忘記在首次提交中包含 .SRCINFO,您可以使用 rebasing with --root 或是 filtering the tree 使得 AUR 接受您的第一次推送
提示:為了保持工作目錄和提交儘可能的乾淨,可以創建 gitignore(5) 文件來排除所有文件,然後再按需添加文件。

維護軟體包[編輯 | 編輯原始碼]

  • 閱讀其他用戶的反饋,並試著聽從建議改進軟體包,這是個學習的過程!
  • 升級軟體包後,不要在評論中加入版本更新信息,這些信息會沖淡更重要的用戶評論。
  • 不要提交軟體包後就放任不管!檢查更新並改進 PKGBUILD 是維護者的責任。
  • 發覺自己不再想維護某個軟體包?可以通過 AUR web 界面 disown 一個軟體包或是在 AUR 郵件列表發條消息。如果這個包的所有維護者都disown,那麼它就會變成一個 「orphaned」 軟體包.

其他事項[編輯 | 編輯原始碼]

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

  • 如果現在的維護者在兩周之內沒有反應,orphan 請求就會通過。
  • 合併請求會刪除軟體包 base,並將現有的投票數、評論轉移到另一個軟體包 base 中。將要合併到的軟體包 base 是必須的。請注意這和 git merge 或者 GitLab 的 merge request 沒有任何關係。
  • 移除請求需要如下信息(務必用英語):
    • 簡要解釋請求刪除的原因。注意僅僅在軟體包下評論是不足以指出需要刪除的原因的。因為在 TU 採取行動之前,aur-requests 是唯一能取得這些信息的地方。
    • 支持刪除原因的詳細內容,例如這個軟體包已經由另一個軟體包提供。
    • 移除請求可能會被拒絕。例如如果您是維護者的話,您很有可能被建議 disown 這個軟體包,以便讓其他打包者認領。
    • 軟體包被刪除之後,它的 Git 倉庫仍然能從 AUR 中被獲取。