软件包维护者指南

出自 ArchWiki
(重定向自 AUR 软件包维护者指南)

相关文章

软件包维护者是 Arch Linux 的工作人员，负责维护 AUR 的正常运行。他们维护流行的软件包（根据需要与上游沟通并发送补丁），并在管理事务中投票。软件包维护者由当前的软件包维护者通过民主程序从活跃的社区成员中选举产生。软件包维护者是在 AUR 方向上拥有最终决定权的唯一成员。

软件包维护者受《软件包维护者章程》管辖

新软件包维护者待办事项列表

  1. 阅读这篇完整的 Wiki 文章。
  2. 阅读《软件包维护者章程》。
  3. 确保您在 AUR 上的账户详细信息是最新的。
  4. 请您的赞助人之一授予您在 AUR 上的软件包维护者身份。
  5. 提醒一位行政员将您的 wiki 账户添加到 Arch Linux 软件包维护者组。
  6. 提醒一位 BBS 管理员更改您在论坛上的账户。
  7. 向您的赞助人之一索取 #archlinux-staff 和 #archlinux-packaging 频道的密钥，并在频道中加入我们（这不是强制性的，但这是了解团队成员和协作的好方法）。
    • 如果您需要跳板机，请向 heftig 索取 Matrix 邀请。
    • 如果您想要一个 @archlinux/package-maintainer/username cloak，请联系我们的群组联络人为您获取一个。
  8. 请您的赞助人之一在 infrastructure 仓库的 issue tracker 中创建一个工单（使用 Onboarding 模板），并向他们提供以下信息
    • 一个 SSH 公钥。如果您没有，请按照 SSH 密钥#生成 SSH 密钥对 创建一个。
    • 一个用户名，将用于您的 SSO 账户和您（即将创建）的 @archlinux.org 电子邮件地址。
    • 您的全名。
    • 您的（个人）电子邮件地址以及其有效的 PGP 公钥 ID，这将用于为您提供开发者界面 (archweb) 的初始密码，并将链接到您（即将创建）的 SSO 账户。
    • 您的私人电子邮件地址或您（即将创建）的 username@archlinux.org 电子邮件地址是否应用于非公开邮件列表，并允许发布到 arch-dev-public 邮件列表。
  9. 按照 DeveloperWiki:Staff Services#Email 设置您的 @archlinux.org 电子邮件地址的密码。
  10. 按照 添加新软件包维护者密钥的工作流程（使用您新的 username@archlinux.org 地址作为 uid）创建用于软件包签名的 PGP 密钥对。
  11. 请您的赞助人之一在 archlinux-keyring 仓库的 issue tracker 中创建一个工单（使用 New Packager Key 模板），以便您的 PGP 密钥由（至少）三位主密钥持有者签名。
  12. 安装 devtools 软件包。
  13. 为 repos.archlinux.org 配置您的私有 ssh 密钥。
  14. Ssh 连接到 yourname@repos.archlinux.org（一旦您获得权限）。
  15. 开始贡献吧！

初级维护者

自从 RFC 0014 批准后，新的软件包维护者将在其最初两个月的软件包维护期间被标记为“初级”。在此期间，新的软件包维护者只能推送到 extra-testing 仓库。您的赞助人可以根据需要审查您的软件包，并将其移至 extra 仓库。

软件包维护者与 AUR

软件包维护者还应努力检查 AUR 中的软件包提交，以查找恶意代码和良好的 PKGBUILD 编写标准。在大约 80% 的情况下，AUR 中的 PKGBUILD 非常简单，软件包维护者团队可以快速检查其合理性和恶意代码。

软件包维护者还应检查 PKGBUILD 中的小错误，并提出更正和改进建议。软件包维护者应努力确认所有软件包都遵循 Arch 软件包指南/标准，并在此过程中与其他软件包构建者分享他们的技能，以努力提高整个发行版的软件包构建标准。

软件包维护者还处于记录推荐实践的绝佳位置。

重写 git 历史

在某些情况下，需要重写 AUR 仓库的历史记录，例如，当用户在已发布的提交中不小心使用了他们的法定姓名时。这可以使用 git-filter-branch(1) 自动化完成。

要强制推送新历史记录，请将 AUR_OVERWRITE=1 环境变量转发到 git-push(1)。

详细来说，这包括将 SendEnv AUR_OVERWRITE 添加到您的 AUR SSH 配置，并在您的推送命令中设置环境变量：AUR_OVERWRITE=1 git push --force。有关详细信息，请参阅 [1]。

警告： 建议在重写历史记录之前创建仓库的备份。
修改提交者或作者身份

安装 git-filter-repo 并运行

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

或者，使用 git filter-branch --env-filter 以及 GIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL、GIT_COMMITTER_NAME 和 GIT_COMMITTER_EMAIL 环境变量。例如

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) 默认只显示 git 作者。使用 git log --pretty=fuller 显示作者和提交者。

处理 AUR 请求

本文或本节需要扩充。

原因： 此列表目前不完整，应进行扩充。（在 Talk:Package Maintainer guidelines 中讨论）

软件包维护者应定期检查 AUR 上提交的请求。为此，有一些通用规则来检查每种请求类型

孤儿请求
  • 检查请求是否超过 14 天（日期列在概览中变为红色）（无论如何您都不能在此之前接受它）
  • 检查过去 14 天内是否没有对软件包本身进行更新（提交或发布）
  • 检查过去 14 天内是否没有来自 AUR 软件包维护者的评论

如果以上所有点都为真，那么您可以接受孤儿请求。

软件包维护者与 extra 仓库，软件包维护指南

软件包进入 extra 仓库的规则

  • 软件包不得已存在于任何 Arch Linux 仓库中。您应采取必要的预防措施，以确保没有其他打包者正在推广相同的软件包。仔细检查 AUR 软件包评论，阅读 aur-general 中的最新主题标题，grep git-log(1)，并向私有打包 IRC 频道发送快速消息。
  • Pacman 包装器作为特殊例外，永远不允许使用。如果想要添加其他 AUR 助手，请向 arch-dev-public 发送电子邮件，说明提议的添加内容，并尊重团队成员提出的任何异议。

本文或本节的事实准确性存在争议。

原因： 以下规则是任意的，在实践中并未强制执行。接下来的两点也需要调整。（在 Talk:Package Maintainer guidelines 中讨论）
  • 只有“流行的”软件包才能进入仓库，定义为来自 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 仓库

按照软件包维护者指南中的说明，将软件包从 extra-testing 仓库移至 extra 仓库。

在 build.archlinux.org 上远程构建

警告： 以下程序破坏了信任网络模型：拥有 PKGBUILD.com root 访问权限的用户可以在软件包发布之前更改软件包和/或签名。

软件包维护者和开发者可以通过 SSH 连接到 build.archlinux.org，以便使用 devtools 构建软件包等。与本地设置相比，这有很多优势

  • 构建速度快，网络速度高。
  • 环境只需设置一次。
  • 您的本地系统不必是 Arch Linux。

该过程类似于使用 devtools 进行本地设置。您的 GnuPG 私钥是签名所必需的，但出于明显的安全原因，您不想上传它。因此，您需要将 GnuPG 代理套接字从本地计算机转发到服务器：这将允许您在构建服务器上签名软件包，而无需传输您的密钥。这也意味着我们需要在服务器上禁用代理，然后才能运行任何操作。

首先，连接到 build.archlinux.org 并禁用

$ ssh build.archlinux.org
$ systemctl --user mask gpg-agent.service

确保 gpg-agent 未运行 (systemctl --user stop gpg-agent.service)。此时，确保 gpgconf --list-dir socketdir 指向的文件夹中不存在套接字。如果存在，请删除它们或注销并重新登录。如果您有自定义的 $GNUPGHOME（例如，将其移动到 ~/.config/gnupg），您需要取消设置它，因为在 gnupg 中，如果不设置 socketdir，则无法设置 homedir。在 build.archlinux.org 上，sshd_config 中设置了 StreamLocalBindUnlink yes，因此无需在注销时手动删除套接字。

虽然 PGP 私钥保留在您的本地计算机上，但公钥必须在构建服务器上。将您的公钥环导出到构建服务器，例如从您的本地计算机

$ scp ~/.gnupg/pubring.gpg build.archlinux.org:~/.gnupg/pubring.gpg

SSH 是检出和提交到 Git 仓库所必需的。您可以在服务器上设置新的 SSH 密钥对（出于安全原因，强烈建议不要将您的本地私钥放在服务器上），或者通过套接字转发重用您的本地密钥。如果您选择后者，请确保在构建服务器上禁用 ssh-agent（如果您之前已启用它，默认情况下它未运行）。

在构建服务器上配置您的构建环境

~/.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..."
警告： 将您的 gpg-agent 套接字转发到远程计算机会使任何具有该系统 root 访问权限的人员都可以使用您未锁定的 GPG 凭据。为了规避此问题，我们需要禁用密码缓存。

使用以下设置禁用密码缓存

gpg-agent.conf
default-cache-ttl 0
max-cache-ttl 0

因为我们希望保持我们常用的 GPG 代理以其当前设置运行，所以我们将运行另一个专用于当前任务的 GPG 代理。创建一个 ~/.gnupg-archlinux 文件夹，并将 ~/.gnupg 中的所有内容符号链接到那里，除了 ~/.gnupg/gpg-agent.conf。配置新的 GPG 代理

~/.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

gpg-agent-extra.socket 将被转发到 build.archlinux.org。

使用以下命令启动专用代理

$ gpg-agent --homedir ~/.gnupg-archlinux --daemon

使用以下命令连接

$ 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

或者，如果使用 GnuPG 作为您的 SSH 代理

$ 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

将 REMOTE_UID 和 LOCAL_UID 替换为您的用户标识符，分别由构建服务器和本地的 id -u 返回。如果使用 ssh-agent，请将 REMOTE_SSH_AUTH_SOCK 替换为远程主机上 SSH 套接字的路径（可以是任何内容）。

您可以使该主机的转发永久生效。例如使用 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

再次，将 REMOTE_UID 替换为构建服务器上的用户 UID。

从那时起，过程应与本地构建完全相同

$ ssh build.archlinux.org
$ pkgctl repo clone existing-package
$ ...
注意： pinentry-curses 可能无法与套接字转发一起使用。如果对您不起作用，请尝试使用不同的 pinentry。

软件包维护者退休待办事项列表

当软件包维护者辞职时，应遵循以下列表，当软件包维护者辞职但仍是开发者时，这些步骤不适用。

  1. 所有由退休人员打包的软件包都应重新签名（即重新构建）。由退休人员打包的软件包可以在 Archweb https://archlinux.org.cn/packages/?sort=&q=&packager=$packager&flagged= 中找到，其中 packager 是 Archweb 上的用户名。
  2. 退休人员的账户应在 Archweb 上禁用，并添加到“退休软件包维护者”组。应将退休人员从“软件包维护者”中移除，并且仓库权限应降至无。
  3. 应禁用对我们服务器的 shell 访问权限。（特别是 repos.archlinux.org, pkgbuild.com）
  4. 应删除 GPG 密钥，并将新的 archlinux-keyring 软件包推送到仓库。在 keyring 项目中创建错误报告，以删除退休软件包维护者的密钥。
  5. 从他们的 AUR 账户中移除软件包维护者组。
  6. 一位行政员应从 Arch Linux 软件包维护者组中移除他们的 wiki 账户。
  7. 一位 BBS 管理员应更改他们在论坛上的账户。
检索自“https://wiki.archlinux.org.cn/index.php?title=Package_Maintainer_guidelines&oldid=822754”