软件包维护者指南

出自 ArchWiki

相关条目

软件包维护者是 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 披风，请咨询我们的 群组联系人 以获取。
  8. 请您的赞助者之一在 基础设施仓库 issue 跟踪器 中创建一个工单（使用 Onboarding 模板），并向他们提供以下信息
    • SSH 公钥。如果您没有公钥，请按照 SSH 密钥#生成 SSH 密钥对 创建一个。
    • 用户名，这将用于您的 SSO 账户和您（将要创建）的 @archlinux.org 电子邮件地址。
    • 您的全名。
    • 您的（个人）电子邮件地址和一个有效的 PGP 公钥 ID，这将用于为您提供开发者界面 (archweb) 的初始密码，并链接到您（将要创建）的 SSO 账户。
    • 您的私人电子邮件地址还是您（将要创建）的 username@archlinux.org 电子邮件地址应用于非公开邮件列表，并允许发布到 arch-dev-public 邮件列表。
  9. 按照 DeveloperWiki:员工服务#电子邮件 设置您的 @archlinux.org 电子邮件地址的密码。
  10. 按照添加新的打包者密钥的工作流程（使用您新的 username@archlinux.org 地址作为 uid）为 软件包签名 创建 PGP 密钥对。
  11. 请您的赞助者之一在 archlinux-keyring 仓库 issue 跟踪器 中创建一个工单（使用 New Packager Key 模板），以便让您的 PGP 密钥由（至少）三位主密钥持有者签名。
  12. 安装 devtools 软件包。
  13. 配置您的私有 ssh 密钥 以访问 repos.archlinux.org。
  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 配置，并在您的推送命令中设置 env var：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 上远程构建

警告： 以下程序破坏了 Web Of Trust 模型：具有对 PKGBUILD.com 根访问权限的用户可以在软件包发布之前更改软件包和/或签名。

软件包维护者和开发者可以通过 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 上，StreamLocalBindUnlink yes 在 sshd_config 中设置，因此无需在注销时手动删除套接字。

虽然 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”