跳转至内容

软件包维护者指南

来自 ArchWiki

相关文章

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

软件包维护者遵循 软件包维护者章程进行管理。

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

  1. 阅读整个 wiki 文章。
  2. 阅读 软件包维护者章程。
  3. 确保您在 AUR 上的账户信息是最新的。
  4. 请您的赞助人之一为您在 AUR 上授予软件包维护者状态。
  5. 提醒一位 管理员（查看 ArchWiki:Maintenance Team#Active maintainers 以获取活跃列表）将您的 wiki 账户添加到 Arch Linux 软件包维护者组。
  6. 提醒一位 BBS 管理员更改您在论坛上的账户。
  7. 请您的赞助人之一提供 #archlinux-staff 和 #archlinux-packaging 的密钥，并加入我们的频道（这不是强制性的，但这是了解团队部分成员和协作的好方法）。
    • 如果您需要一个 bouncer，请向 heftig 申请一个 Matrix 邀请。
    • 如果您想要一个 @archlinux/package-maintainer/username 的 cloak，请联系我们的 群组联系人为您获取一个。
  8. 请您的赞助人之一在 基础设施仓库的 issue tracker 中创建一个（使用 Onboarding 模板）工单，并向他们提供以下信息：
    • 一个 SSH 公钥。如果您没有，请按照 SSH keys#Generating an SSH key pair 生成一个。
    • 一个用户名，将用于您的 SSO 账户以及您（将要创建的）@archlinux.org 电子邮件地址。
    • 您的全名。
    • 您的（个人）电子邮件地址以及该地址的一个有效 PGP 公钥 ID，用于向您提供开发者界面（archweb）的初始密码，并会链接到您的（将要创建的）SSO 账户。
    • 您的私人电子邮件地址或您（将要创建的）username@archlinux.org 电子邮件地址应被用于非公开邮件列表，并允许发布到 arch-dev-public 邮件列表。
  9. 按照 DeveloperWiki:Staff Services#Email 设置您的 @archlinux.org 电子邮件地址的密码。
  10. 为 软件包签名创建一个 PGP 密钥对，遵循 添加新打包者密钥的工作流程（使用您的新 username@archlinux.org 地址作为 uid）。
  11. 请您的赞助人之一在 archlinux-keyring 仓库的 issue tracker 中创建一个（使用 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)。

详细来说，这包括在您的 AUR SSH 配置中添加 SendEnv AUR_OVERWRITE，并在您的推送命令中设置环境变量：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 提升到 extra 时，始终将 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 agent socket 从本地机器转发到服务器：这将允许您在构建服务器上签名软件包，而无需传输您的密钥。这也意味着我们需要在服务器上禁用 agent，然后才能运行任何东西。

首先，连接到 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 指向的文件夹中没有 socket。如果存在，请删除它们或注销并重新登录。如果您有自定义的 $GNUPGHOME（例如，将其移动到 ~/.config/gnupg），您需要取消设置它，因为 gnupg 无法在不设置 socketdir 的情况下设置 homedir。在 build.archlinux.org 上，sshd_config 中设置了 StreamLocalBindUnlink yes，因此注销时手动删除 socket 不是必需的。

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

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

SSH 是检出和提交到 Git 仓库所必需的。您可以选择在服务器上设置一个新的 SSH 密钥对（出于安全原因，强烈建议不要将本地私钥放在服务器上），或者通过 socket 转发重用您的本地密钥。如果您选择后者，请确保在构建服务器上禁用 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 socket 转发到远程机器，使得该系统上的任何 root 用户都可以使用您解锁的 GPG 凭据。为了规避此问题，我们需要禁用密码短语缓存。

使用以下设置禁用密码短语缓存：

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

因为我们希望我们的常规 GPG agent 保持运行并使用其当前设置，所以我们将运行另一个专门用于此任务的 GPG agent。创建 ~/.gnupg-archlinux 文件夹并将 ~/.gnupg 中的所有内容链接到此处，但 ~/.gnupg/gpg-agent.conf 除外。配置新的 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

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

使用以下命令启动专用 agent：

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

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

您可以使该转发对该主机永久生效。例如，使用 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 可能无法与 socket 转发一起使用。如果它对您不起作用，请尝试使用不同的 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 项目中创建 bug 报告以删除已退休软件包维护者的密钥。
  5. 从他们 AUR 账户中移除软件包维护者组。
  6. 一位 管理员应将其 wiki 账户从 Arch Linux 软件包维护者组中移除。
  7. 一位 BBS 管理员应更改其在论坛上的账户。
取自 "https://wiki.archlinux.org.cn/index.php?title=Package_Maintainer_guidelines&oldid=848482"

© . This site is unofficial and not affiliated with Arch Linux.

Content is available under GNU Free Documentation License 1.3 or later unless otherwise noted.