用戶可以通過 AUR 分享 PKGBUILD 腳本。AUR 中不包含任何二進位包,僅包含用戶上傳的 PKGBUILD,供其他用戶下載使用。所有軟體包都是非官方的,使用風險自擔。
提交軟體包
如果對自己的 PKGBUILD 缺乏信心,可以先把它貼到AUR 郵件列表,論壇 AUR 版或 IRC 頻道,讓大家幫您檢查。
提交軟體包的規則
提交軟體包時請遵循下列的規則:
- 仔細檢查上傳的文件。編寫PKGBUILD前務必閱讀 Arch軟體打包標準。劣質的 PKGBUILD 會影響軟體的正常使用,不要指望別人會因為您糟糕的 PKGBUILD 浪費了他們的時間而收到感謝。
- 任何提交的
PKGBUILD
都不能編譯已經位於官方二進位軟體包倉庫的程序。如果認為官方倉庫的軟體包已過期,請標記它。如果它有問題或者缺少功能,請反饋反饋bug報告。
-
唯一的例外是和官方打包版本相比增加或開啟了新的功能或者使用了不同的補丁。這時需要修改 pkgname 來表示新增的功能。例如加入了邊欄支持的
screen
應該命名為screen-sidebar
。此外還需要同時添加conflicts=('screen')
以避免與官方倉庫中的包衝突。
- 檢查 AUR 中是否已有相同軟體包。如果已經有人維護某軟體包,可以以評論的形式將變化報告給維護人員。如果軟體包無人維護或不存在,用戶提交的軟體包將被認領。別創建重複的包。
- 確保您的軟體包有人需要。在提交前請仔細想想:有人會用這個軟體包嗎?它非常特別嗎?如果不是只有少數人覺得它有用,就提交它。
- AUR 和官方軟體倉庫中計劃放置通用軟體和軟體相關的內容,包括:可執行文件、配置文件、軟體的在線/離線文檔和軟體直接使用的媒體數據。
- 不要在 AUR
PKGBUILD
中使用replaces
,除非這個軟體包將要被重命名(例如當 Ethereal 變成 Wireshark 時)。如果這個軟體包是已經存在的軟體包的另一版本,使用conflicts
(或者如果這個軟體包被其他軟體需要時,使用provides
)。兩者的主要區別是:在 pacman 同步(-Sy)之後,如果遇到與replaces
匹配並已經安裝的軟體包時,pacman 會立刻想去替換它。而conflicts
則在安裝軟體包時進行替換。 - 請為那些由版本控制系統構建,而不屬於任何特定版本的軟體包的包名添加合適的後綴,如
-git
。具體細則見 VCS 軟體打包準則#軟體包命名。 - 如果原始碼是可取得的,請避免提交二進位文件。AUR不應當包含
makepkg
創建的二進位包,也不應當包含文件列表。 - 當源碼可獲得時,那些預構建可以直接部署的二進位包應該加上
-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 key 。將公鑰導入到用戶帳戶的 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.
如果您已經有一個軟體包了,如果它不是 Git 倉庫的話,初始化:
$ git -c init.defaultBranch=master init
並添加遠程 AUR 地址:
$ git remote add label ssh://aur@aur.archlinux.org/pkgbase.git
然後從遠程獲取文件並初始化。
pkgbase
匹配到已刪除軟體包的衝突問題。提交和更新軟體包
git config user.name [...]
和 git config user.email [...]
編輯自己的本地身份!當釋出新版本的軟體時,更新 pkgver 或者 pkgrel 變量來提示所有的用戶更新。如果僅僅是對 PKGBUILD 的小修改(例如修正筆誤),請不要更新這些變量。
不要僅僅為了更新pkgvar
就更新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
,您可以使用 changing your last commit 之後運行git commit --amend
或是 filtering the tree 使得 AUR 接受您的推送
維護軟體包
- 閱讀其他用戶的反饋,並試著聽從建議改進軟體包,這是個學習的過程!
- 升級軟體包後,不要在評論中加入版本更新信息,這些信息會沖淡更重要的用戶評論。
- 不要提交軟體包後就放任不管!檢查更新並改進
PKGBUILD
是維護者的責任。 - 發覺自己不再想維護某個軟體包?可以通過 AUR web 界面
disown
一個軟體包或是在 AUR 郵件列表發條消息。如果這個包的所有維護者都disown,那麼它就會變成一個"orphaned"軟體包。 - 自動化對維護人員來說是有價值的工具,但它不能取代人工干預(例如:項目可能會修改許可證、添加或刪除依賴關係,以及其它在「小版本」中的顯著更改)。自動更新
PKGBUILD
的風險將由您自行承擔,任何出現問題的帳戶與他們提交的軟體包都可能被無事前通知地刪除。
其他事項
刪除、合併、取消維護權限請求可以通過右側 "Package actions" 的 "File Request" 連結執行。這會給當前的維護者和 aur-requests 郵件列表自動發送郵件通知。軟體包維護者會接受或拒絕請求。
刪除
你可以請求 unlist AUR 中的一個pkgbase
。提交時請附上原因說明,也可以是其他有用的細節。(比方說其他包提供了相同的東西,或者你就是這個包的維護者,又或者是它被重命名並經過軟體包所有者同意,等等)。
- 只在軟體包的評論區解釋原因並不夠。當包維護者想要刪除時,目前來說唯一有效的方式是在 aur-request 郵件列表中解釋。
- 刪除請求可能被否決。比如當這個包的維護者是你時,我們可能會建議你只放棄維護,並允許其他人來維護它。
移除請求需要如下信息(務必用英語):
- 簡要解釋請求刪除的原因。注意僅僅在軟體包下評論是不足以指出需要刪除的原因的。因為在 TU 採取行動之前,aur-requests 是唯一能取得這些信息的地方。
- 支持刪除原因的詳細內容,例如這個軟體包已經由另一個軟體包提供。
- 移除請求可能會被拒絕。例如如果您是維護者的話,您很有可能被建議 disown 這個軟體包,以便讓其他打包者認領。
- 軟體包被刪除之後,它的 Git 倉庫仍然能從 AUR 中被獲取。
合併
合併請求會刪除軟體包 base,並將現有的投票數、評論轉移到另一個軟體包 base 中。將要合併到的軟體包 base 是必須的。 這個操作是在例如上游進行了重命名項目時使用的。
取消維護權限
如果你要求撤銷現有維護者對pkgbase
的所有權,而該維護者在兩周之內沒有反應,取消維護權限請求就會通過。另外,如果一個軟體被標記為過期超過180天,請求會被自動通過。