軟件包維護者指導原則
軟件包維護者是負責使 AUR 正常工作的 Arch Linux 工作人員。他們負責維護熱門軟件包(並在必要時與上游項目溝通或者向上游項目提交補丁),並且參與管理事務的表決。新的軟件包維護者由現任包維護者從活躍的社區成員中民主選舉產生,包維護者是唯一有權決定 AUR 發展方向的成員群體。
軟件包維護者們根據軟件包維護者細則來管理社區。
新軟件包維護者的 TODO 列表[編輯 | 編輯原始碼]
- 仔細閱讀本頁面
- 閱讀軟件包維護者細則
- 確認自己在 AUR 的賬戶信息是最新的
- 讓一個推薦人在 AUR 中給您軟件包維護者狀態
- 提醒 bureaucrat 將你的維基賬號添加到 ⧼group-archpackager⧽ 組
- 提醒 BBS 管理員更改你在論壇上的賬戶
- 讓推薦人提供 #archlinux-staff 和 #archlinux-packaging 密碼,並加入頻道(非必須,但有助於團隊成員相互認識併合作)
- 如果需要 bouncer,請找 heftig 申請加入 Matrix
- 如果需要
@archlinux/trusteduser/username
,請連續群組聯絡人 group contacts - 如果想要
@archlinux/package-maintainer/username
cloak,請找群組聯繫人進行協助
- 讓一個贊助者在基礎設施倉庫問題追蹤中使用
Onboarding
模板創建工單,並提供如下信息:- 一個 SSH 公鑰,如果還沒有,參考 SSH 密鑰#生成密鑰對 生成一個。
- SSO 帳號要使用的用戶名,此名稱也會用來創建
@archlinux.org
郵箱地址。 - 全名
- 個人郵箱地址和對應的有效 PGP 公鑰 ID,該信息將用於提供連結到 SSO 賬戶的開發者界面(archweb)初始密碼
- 是否將你的私人或(尚未創建的)
username@archlinux.org
郵箱地址用在非公開郵件清單,並允許發佈到 arch-dev-public 郵件清單
- 按照 arch:DeveloperWiki:Staff Services#Email 配置
@archlinux.org
郵箱的密碼 - 參考添加新打包人密鑰的流程創建用於軟件包簽名的新 PGP 密鑰對(使用新的
username@archlinux.org
郵箱地址作為 uid) - 讓一位推薦人在 archlinux-keyring 代碼庫問題追蹤頁使用
New Packager Key
模板創建工單,以使你的 PGP 密鑰受至少三個主密鑰持有者簽名 - 安裝 devtools包 軟件包
- 為
repos.archlinux.org
配置你的 ssh 私鑰 - 獲得權限後,ssh 到
yourname@repos.archlinux.org
- 開始你的貢獻吧!
初級維護者[編輯 | 編輯原始碼]
Since the ratification of RFC 0014, new Package Maintainers will be marked as "junior" for their first two months of packaging. During this time, the new Package Maintainer may only push to the extra-testing repository. Your sponsors can review your packages as-needed and move them to extra.
軟件包維護者與 AUR[編輯 | 編輯原始碼]
軟件包維護者應檢查被提交到 AUR 中的軟件包是否含有惡意代碼,以及 PKGBUILD 是否符合標準。80% 左右的 PKGBUILD 都非常簡單,包維護者團隊可以很快地檢查其可用性以及安全性。
軟件包維護者也應該檢查 PKGBUILD 的一些小錯誤,提出修正和改進建議。軟件包維護者應該努力確認所有的軟件包是否遵循了 Arch 打包指導準則/標準,並與其他打包者分享他們的技能和經驗來提升 archlinux 的總體軟件打包質量。
另外,也建議軟件包維護者撰寫文檔來記錄一些推薦做法。
Rewriting git history[編輯 | 編輯原始碼]
In some cases rewriting the history of an AUR repository is required, for example when a user inadvertently uses their legal name in a published commit. This can be automated with git-filter-branch(1).
To force push the new history, forward the AUR_OVERWRITE=1
environment variable to git-push(1).
In detail this includes adding SendEnv AUR_OVERWRITE
to your AUR SSH config and setting the env var on your push command: AUR_OVERWRITE=1 git push --force
.
See [1] for details.
- Modify committer or author identity
Install git-filter-repo包 and run:
$ git-filter-repo --name-callback 'return name.replace(b"Old name", b"New name")' --email-callback 'return email.replace(b"old@email.com", b"new@email.com")'
name.replace("Bás Ssze".encode("utf-8"), b"newname")'
Alternatively, use git filter-branch --env-filter
with the GIT_AUTHOR_NAME
, GIT_AUTHOR_EMAIL
, GIT_COMMITTER_NAME
and GIT_COMMITTER_EMAIL
environment variables. For example:
git filter-branch --env-filter ' if test "$GIT_AUTHOR_EMAIL" = "lepetit@prince.com"; then GIT_AUTHOR_EMAIL=user@users.noreply.github.com fi if test "$GIT_AUTHOR_NAME" = "Antoine de Saint-Exupéry"; then GIT_AUTHOR_NAME=user fi'
git log --pretty=fuller
to display the author and committer.Handling AUR requests[編輯 | 編輯原始碼]
Package Maintainers should periodically check the requests filed on the AUR. For that there are some generic rules what to check for each request type:
- Orphan request
- check if the request is older then 14 days (the date column turns red in the overview) (you cannot accept it before that anyway)
- check if there was no update to the package itself (commit or release) done in the past 14 days
- check if there was no comment from the AUR package maintainer done in the past 14 days
If all of the above points are true then you can accept the Orphan Request.
軟件包維護者與 extra,軟件包維護準則[編輯 | 編輯原始碼]
軟件包進入 [extra] 倉庫的規則[編輯 | 編輯原始碼]
- 軟件包不能存在於任何 Arch Linux 倉庫中。你還需要確保沒有其他打包者同時提交該軟件包。檢查 AUR 的包評論,閱讀 aur-general 中新文章的標題,grep git-log(1) 日誌,並向私密打包 IRC 頻道發送消息。
- Pacman 封裝是一個特例,不管投票數有多高,都不會被批准進入。如果是 AUR 助手,可以寫封郵件到
arch-dev-public
進行提議,並尊重團隊成員提出的反對意見。
- 只有「流行」的軟件包才能進入倉庫(指 pkgstats 有 1% 使用數或者 AUR 中 10 票以上
- 自動略過該規則的軟件包有:
- i18n 包
- 輔助功能軟件包
- 驅動程序
- 滿足「流行」定義的軟件包的依賴包,包括 makedeps 和 optdeps
- 屬於同一集合併一起發佈的軟件包,前提是這一集合的某些軟件包滿足「流行」定義
- 任何不屬於上述例外的其它軟件包都需首先在 aur-general 郵件列表中提出申請,並解釋成為例外的原因(例如重命名的軟件包、新軟件包等)。軟件包進入 extra 倉庫需要其他三名軟件包維護者同意。維護大量「不流行」軟件包的軟件包維護者的申請更有可能被拒絕。
- 強烈建議軟件包維護者移除 extra 倉庫中他們維護的低使用率軟件包。該項非強制,但在有人接手前離職維護者的軟件包有可能會被過濾掉
- 軟件包從 AUR 提升到其它倉庫時,應該將 pkgrel 的數值加 1(即設為 n + 1),這樣已安裝軟件包的用戶可以從官方倉庫繼續收到自動更新。還有一個好處就是避免 pkgrel 重置為 1 時用戶收到本地軟件包比倉庫更新的警告
- 所有官方軟件包的構建腳本都以 0BSD 許可證[2]提供。如果 AUR 包的構建腳本沒有顯式以 0BSD 進行許可,則需要進行重寫
訪問並更新倉庫[編輯 | 編輯原始碼]
參考軟件包維護者指引。
停止維護軟件包[編輯 | 編輯原始碼]
如果一個軟件包維護者不想再維護一個軟件包了,需要在 AUR 郵件列表中發出一個通知,以便其他的軟件包維護者可以接手。即使沒有人接手,軟件包維護者也可以停止維護,但應避免放棄大量軟件包(即不應接手超出能力範圍的包數量)。如果一個軟件包已經過時或不再被使用,那麼可以將其完全移除。
如果一個軟件包已經被完全移除,可以將其重新上傳到 AUR,使得普通用戶可以替軟件包維護者進行維護。
將軟件包從 AUR 移到 extra[編輯 | 編輯原始碼]
遵循打包者指引中將軟件包添加到 extra 的正常步驟即可,但記得將對應的包從 AUR 中移除!
將軟件包從 extra 移至 AUR[編輯 | 編輯原始碼]
按照打包者指引移除軟件包,並將原始碼上傳到 AUR 即可。
將軟件包從 extra-testing 移至 extra[編輯 | 編輯原始碼]
Move the package from the extra-testing to the extra repository using the instructions in the packager guide.
在 build.archlinux.org 上遠程編譯[編輯 | 編輯原始碼]
軟件包維護者和開發者可以 SSH 到 build.archlinux.org,並使用 devtools 編譯軟件包。 和本地編譯相比,這樣做有如下好處:
- 編譯快,網速快
- 環境僅需要配置一次
- 本地系統可以不是 Arch Linux
The process is similar to that of a local setup with devtools. Your GnuPG private is required for signing but you do not want to upload it for obvious security reasons. As such, you will need to forward the GnuPG agent socket from your local machine to the server: this will allow you to sign packages on the build server without communicating your key. This also means that we need to disable the agent on the server before we can run anything.
First, connect to build.archlinux.org and disable
$ ssh build.archlinux.org $ systemctl --user mask gpg-agent.service
Make sure gpg-agent is not running (systemctl --user stop gpg-agent.service
). At this point, make sure that no sockets exist in the folder pointed by gpgconf --list-dir socketdir
. If they do, remove them or log out and in again.
If you have a custom $GNUPGHOME (eg. to move it to ~/.config/gnupg
), you will need to unset that, as it is not possible in gnupg to set the homedir without setting the socketdir.
On build.archlinux.org, StreamLocalBindUnlink yes
is set in sshd_config
, therefore removing the sockets manually on logout is not necessary.
While the PGP private keys remain on your local machine, the public keys must be on the build server. Export your public ring to the build server, e.g. from you local machine
$ scp ~/.gnupg/pubring.gpg build.archlinux.org:~/.gnupg/pubring.gpg
SSH is required to checkout and commit to the Git repository. You can either set up a new SSH key pair on the server (it is highly discouraged to put your local private key on a server for security reasons) or reuse your local keys via socket forwarding. If you opt for the latter, make sure to disable ssh-agent on the build server if you had enabled it previously (it is not running by default).
Configure you build environment on the build server:
~/.makepkg.conf
PACKAGER="John Doe <john@doe.example>" ## Optional PKGDEST="/home/johndoe/packages" SRCDEST="/home/johndoe/sources" SRCPKGDEST="/home/johndoe/srcpackages" LOGDEST="/home/johndoe/logs" ## If your PGP key is not the default, specify the right fingerprint: GPGKEY="ABCD1234..."
Disable passphrase caching with the following settings:
gpg-agent.conf
default-cache-ttl 0 max-cache-ttl 0
Because we will want to keep our usual GPG agent running with its current settings, we are going to run another GPG agent dedicated to the task at hand. Create a ~/.gnupg-archlinux
folder and symlink everything from ~/.gnupg
there, except ~/.gnupg/gpg-agent.conf
. Configure the new GPG agent:
~/.gnupg-archlinux
extra-socket /home/doe/.gnupg-archlinux/S.gpg-agent.extra default-cache-ttl 0 max-cache-ttl 0 pinentry-program /usr/bin/pinentry-gtk-2
The gpg-agent-extra.socket
will be forwarded to build.archlinux.org.
Start the dedicated agent with
$ gpg-agent --homedir ~/.gnupg-archlinux --daemon
Connect with:
$ ssh -R REMOTE_SSH_AUTH_SOCK:$SSH_AUTH_SOCK -R /run/user/REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org
or, if using GnuPG as your SSH agent:
$ ssh -R /run/user/REMOTE_UID/gnupg/S.gpg-agent.ssh:/run/user/LOCAL_UID/gnupg/S.gpg-agent.ssh -R /run/user/REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org
Replace REMOTE_UID
and LOCAL_UID
by your user identifier as returned by id -u
on the build server and locally, respectively.
If using ssh-agent, replace REMOTE_SSH_AUTH_SOCK
by the path to the SSH socket on the remote host (it can be anything).
You can make the forwarding permanent for that host. For instance with gpg-agent.ssh:
~/.ssh/config
Host build.archlinux.org RemoteForward /run/user/REMOTE_UID/gnupg/S.gpg-agent /run/user/%i/gnupg/S.gpg-agent.extra RemoteForward /run/user/REMOTE_UID/gnupg/S.gpg-agent.ssh /run/user/%i/gnupg/S.gpg-agent.ssh
Again, replace REMOTE_UID
with the user UID on the build server.
From then on, the procedure should be exactly the same as a local build:
$ ssh build.archlinux.org $ pkgctl repo clone existing-package $ ...
軟件包維護者辭職需要完成的事項[編輯 | 編輯原始碼]
當一個軟件包維護者辭去自己的職務時,需要完成以下清單。如果僅辭去軟件包維護者,但仍是開發者,就不適用以下步驟。
- 此軟件包維護者的所有包都需要被重新簽名(重新打包)。軟件包維護者編譯的軟件包可以通過下面 URL 從 Archweb 查詢 https://archlinux.org/packages/?sort=&q=&packager=$packager&flagged= ,將 packager 替換成包維護者在 Archweb 的用戶名即可。
- Archweb 需要禁用此維護者的帳號,並將其添加到 'Retired Package maintainers' 組。需從 'Package Maintainers' 移除此軟件包維護者,並收回所有軟件倉庫權限。
- 從伺服器上禁用此帳號的 shell 訪問權限(尤其是 repos.archlinux.org, pkgbuild.com)。
- 移除此用戶的 GPG key,並向倉庫提交新的 archlinux-keyring 軟件包。在 keyring 項目中創建 bug 工單,刪除辭職人員的密鑰。
- 將包維護者的 AUR 帳號移出 Package Maintainer 組。
- bureaucrat 應將維護者的維基賬戶移出 ⧼group-archpackager⧽ 組。
- BBS 管理員需要修改包維護者的論壇帳號。