跳至內容

AUR 提交準則

出自 Arch Linux 中文维基

相關文章

用戶可以通過 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 和官方軟體倉庫是用於放置通用軟體和軟體相關的內容的，包括：可執行文件、配置文件、軟體的在線/離線文檔和軟體直接使用的媒體數據。
  • 不要在 AUR PKGBUILD 中使用 replaces，除非這個軟體包將要被重命名（例如當 Ethereal 變成 Wireshark 時）。如果這個軟體包是已經存在的軟體包的另一版本，使用 conflicts （或者如果這個軟體包被其他軟體需要時，使用 provides）。兩者的主要區別是：在 pacman 同步（-Sy）之後，如果遇到與 replaces 匹配並已經安裝的軟體包時，pacman 會立刻想去替換它。而 conflicts 則在安裝軟體包時進行替換。
  • 當源碼可獲得時，那些預構建可以直接部署的二進制包應該加上 -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>

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

要向 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 天，請求會被自動通過。

取自「https://wiki.archlinuxcn.org/wzh/index.php?title=AUR_提交准则&oldid=30394」