軟體包維護者指導原則 - Arch Linux 中文维基

跳至內容

# 軟體包維護者指導原則

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

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

相關文章

- AUR
- arch:DeveloperWiki:How to be a packager
- arch:DeveloperWiki:Building in a clean chroot
- GnuPG
- OpenPGP

軟體包維護者是負責使 AUR 正常工作的 Arch Linux 工作人員。他們負責維護熱門軟體包（並在必要時與上游項目溝通或者向上游項目提交補丁），並且參與管理事務的表決。新的軟體包維護者由現任包維護者從活躍的社區成員中民主選舉產生，包維護者是唯一有權決定 AUR 發展方向的成員群體。

軟體包維護者們根據軟體包維護者細則來管理社區。

## 新軟體包維護者的 TODO 列表

1. 仔細閱讀本頁面
2. 閱讀軟體包維護者細則
3. 確認自己在 AUR 的帳戶信息是最新的
4. 讓一個推薦人在 AUR 中給您軟體包維護者狀態
5. 提醒 bureaucrat 將你的維基帳號添加到 ⧼group-archpackager⧽ 組
6. 提醒 BBS 管理員更改你在論壇上的帳戶
7. 讓推薦人提供 #archlinux-staff 和 #archlinux-packaging 密碼，並加入頻道（非必須，但有助於團隊成員相互認識併合作）
   - 如果需要 bouncer，請找 heftig 申請加入 Matrix
   - 如果需要 `@archlinux/trusteduser/username`，請連續群組聯絡人 group contacts
   - 如果想要 `@archlinux/package-maintainer/username` cloak，請找群組聯繫人進行協助
8. 讓一個贊助者在基礎設施倉庫問題追蹤中使用 `Onboarding` 模板創建工單，並提供如下信息：
   - 一個 SSH 公鑰，如果還沒有，參考 SSH 密鑰#生成密鑰對生成一個。
   - SSO 帳號要使用的用戶名，此名稱也會用來創建 `@archlinux.org` 郵箱地址。
   - 全名
   - 個人郵箱地址和對應的有效 PGP 公鑰 ID，該信息將用於提供連結到 SSO 帳戶的開發者界面（archweb）初始密碼
   - 是否將你的私人或（尚未創建的）`username@archlinux.org` 郵箱地址用在非公開郵件清單，並允許發布到 arch-dev-public 郵件清單
9. 按照 arch:DeveloperWiki:Staff Services#Email 配置 `@archlinux.org` 郵箱的密碼
10. 參考添加新打包人密鑰的流程創建用於軟體包簽名的新 PGP 密鑰對（使用新的 `username@archlinux.org` 郵箱地址作為 uid）
11. 讓一位推薦人在 archlinux-keyring 代碼庫問題追蹤頁使用 `New Packager Key` 模板創建工單，以使你的 PGP 密鑰受至少三個主密鑰持有者簽名
12. 安裝 devtools包 軟體包
13. 為 `repos.archlinux.org` 配置你的 ssh 私鑰
14. 獲得權限後，ssh 到 `yourname@repos.archlinux.org`
15. 開始你的貢獻吧！

### 初級維護者

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.

警告：It is recommended to create a backup of the repository before rewriting history.

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")'

提示：If the username contains special characters you may need to encode the strings `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(1) only displays the git author by default. Use `git log --pretty=fuller` to display the author and committer.

### Handling AUR requests

這篇文章的某些內容需要擴充。

原因：This list is incomplete for now and should be expanded. (在 Talk:軟體包維護者指導原則 中討論)

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` 進行提議，並尊重團隊成員提出的反對意見。

本文或本章節的事實準確性存在爭議。

原因： The following rule is arbitrary and not enforced in practice. The next two points need to be adjusted as well.（在 Talk:軟體包維護者指導原則 中討論）

- 只有「流行」的軟體包才能進入倉庫（指 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 上遠程編譯

警告：The following procedures defeats the Web Of Trust model: a user with root access to PKGBUILD.com could alter the package and/or the signature before it gets published.

軟體包維護者和開發者可以 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..."

警告：Forwarding your gpg-agent socket to a remote machine makes it possible for anyone with root access to that system to use your unlocked GPG credentials. To circumvent this issue, we need to disable passphrase caching.

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
    $ ...

注意：pinentry-curses might not work with socket forwarding. If it fails for you, try using a different pinentry.

## 軟體包維護者辭職需要完成的事項

當一個軟體包維護者辭去自己的職務時，需要完成以下清單。如果僅辭去軟體包維護者，但仍是開發者，就不適用以下步驟。

1. 此軟體包維護者的所有包都需要被重新簽名（重新打包）。軟體包維護者編譯的軟體包可以通過下面 URL 從 Archweb 查詢 https://archlinux.org/packages/?sort=&q=&packager=$packager&flagged= ，將 packager 替換成包維護者在 Archweb 的用戶名即可。
2. Archweb 需要禁用此維護者的帳號，並將其添加到 'Retired Package maintainers' 組。需從 'Package Maintainers' 移除此軟體包維護者，並收回所有軟體倉庫權限。
3. 從伺服器上禁用此帳號的 shell 訪問權限（尤其是 repos.archlinux.org, pkgbuild.com）。
4. 移除此用戶的 GPG key，並向倉庫提交新的 archlinux-keyring 軟體包。在 keyring 項目中創建 bug 工單，刪除辭職人員的密鑰。
5. 將包維護者的 AUR 帳號移出 Package Maintainer 組。
6. bureaucrat 應將維護者的維基帳戶移出 ⧼group-archpackager⧽ 組。
7. BBS 管理員需要修改包維護者的論壇帳號。

分類：​

- 包開發
- OpenPGP

隱藏分類：​

- 使用「模板:準確性」標記的頁面或章節

軟體包維護者指導原則
新增話題