AUR Trusted User Guidelines (简体中文)

From ArchWiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

相关文章

翻译状态：本文是 AUR_Trusted_User_Guidelines 的翻译。上次翻译日期：2017-09-13。如果英文版本有所更改，则您可以帮助同步翻译。

Trusted User (TU) 是负责使 AUR 正常工作的社区成员。他们维护热门的包（并在必要时与上游项目交涉或者向上游项目发送补丁），并且参与管理事务的表决。TU 由现任的 TU 从活跃的社区成员中民主选举产生。 TU 是唯一具有决定 AUR 发展方向的权利的社区成员群体。

TU们依靠TU bylaws来管理社区。

新 TU 的 TODO 列表

  1. 仔细阅读本页面
  2. 阅读 TU Bylaws
  3. 确认自己在 AUR 的账户详细信息是最新的
  4. 将你自己添加到 Trusted Users 页面
  5. 订阅 Arch Linux 开发邮件列表 arch-dev-public.
  6. 提醒 BBS admin 更改你在论坛上的账户
  7. 向先辈 TU 索要 #archlinux-tu 的密码并挂在上面。这不是必须的，但是这样会更方便。因为那儿是黑历史曝光和新想法提出的地方。
  1. 为软件包签名创建 PGP key 或者使用已有的key，请确保 key 包含加密的 subkey，这样才能收到加密的验证令牌。
  2. 按照此 模板 向 Ionuț Bîru (ibiru@archlinux.org) 或 Florian Pritz (bluewind@xinu.at)发邮件，包含所有信息以获得 dev 接口的访问权限
  3. 给 Florian 发一封加密邮件:
    • 包含一个 SSH 公钥，如果还没有，使用 ssh-keygen 生成。Using SSH Keys 包含更多信息。
    • 要求将你加入 arch-dev-public 白名单.
    • 告诉他你需要一个 @archlinux.org 电子邮箱.
  4. 要求你的赞助者:
    • 在 AUR 赋予你 TU 状态.
    • 在 bug 管理系统的 "Keyring" 项目中提交任务，步骤参考 这里，三个主密钥持有者会签名您的 PGP 密钥。
  5. 给 Lukas Fleischer 发送一封附有 ssh 公钥的邮件。如果你没有一个公钥，使用ssh-keygen来生成一个。更多关于 ssh 密钥的信息请查看 Using SSH Keys 页面
  6. 安装 devtools 软件包
  7. 为主机 orion.archlinux.org 和 repos.archlinux.org 上配置ssh 私钥
  8. Ssh 到 yourname@orion.archlinux.org (得到权限之后).
  9. 如果你在两天内没有在 bugtracker 被升级到 TU 组，在 arch-dev-public 发邮件询问
  10. 开始你的贡献吧！

TU 和 [unsupported]

TU 应该仔细检查那些被提交到 UNSUPPORTED 分类中的软件是否含有恶意代码，以及PKGBUILD包是否符合标准。在UNSUPPORTED 中，大约 80% 的 PKGBUILD 都非常简单，TU 团队可以很快的检查其可用性以及安全性。

TU 也应该检查 PKGBUILD 的一些小错误，提出修改以及改进建议。TU 应该努力确认所有的软件包遵循了Arch Packging Guidelines/Standards 并与其他打包者分享他们的技能和经验来提升 archlinux 的软件包发行版本的质量。

TU 也很适合撰写文档来记录一些值得推荐的行为。

TU 和 [community], 包维护导引

软件包进入 [community] 仓库的规则

  • 只有“流行”的软件包才能进入仓库，如 pkgstats 规定的 1% 使用数或者 AUR 中 10 票以上
  • 自动属于此规则的例外的软件包包括：
    • i18n 包
    • 辅助功能软件包
    • 驱动程序
    • 满足“流行”定义的软件包所依赖的包，包括 makedeps 和 optdeps
    • 属于同一集合并一起发布的软件包，前提是这一集合的某些软件包满足“流行”定义
  • 任何其他不属于上述例外的软件包想要进入仓库都需首先在 aur-general 邮件列表中提出申请，并解释成为例外的原因（例如重命名的软件包、新软件包等）。软件包进入仓库需要其他三名 TU 同意。维护大量的“不流行”软件包的 TU 的申请更有可能被拒绝。
  • 强烈建议 TU 移除 [community] 仓库中他们正在维护的低使用率的软件包。尽管离职的 TU 的软件包在被采用之前会被过滤的情况会发生，移除的行为不会被强制要求
  • 软件包从 AUR 提升到其它仓库时，应该将 pkgrel 的数值加 1，这样已经安装了软件包的用户还可以继续收到软件自动更新。还有一个好处就是避免 pkgrel 重置为 1 时用户收到本地软件包更新的警告.

访问并更新仓库

[community] 仓库现在使用和 [core] 和 [extra] 仓库相同的工具 devtools 来上传软件包。唯一的不同在于 [core] 和 [extra] 使用服务器 https://archlinux.org 而 [community] 仓库使用服务器orion.archlinux.org。因此 Packager Guide 页面中大多数指令都能在不用改动的情况下使用。这里介绍关于 [community] 仓库的一些特殊的信息。devtools 需要软件打包人员 设置 makepkg.conf 中的 PACKAGER 变量.

首先，你应该做一个 [community] 软件仓库的 非递归签出： 

svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community

这一步骤将会创建一个名为 svn-community 的目录，里面只有包含 svn 信息的 .svn 目录。

关于 签出，更新所有软件包或添加一个软件包，请参见 Packager Guide 。

要移除一个软件包： 

 ssh orion.archlinux.org /community/db-remove community arch pkgname

在此以及接下来的文中，arch 可以是 Arch Linux 支持两个平台 i686 或 x86_64。

注意： 如果编辑的是 any 架构的软件包，可以按 x64 执行，一般都能正常使用。

当你完成了 PKGBUILD 等之后，你应该 提交 你的更改（svn commit）。

用 mkarchroot 或帮助脚本 extra-i686-build/extra-x86_64-build 编译软件包. 如该要上传到 testing，也需要 testing-i686-build 和 testing-x86_64-build.

用 gpg --detach-sign *.pkg.tar.xz 签署软件包. 如果使用不同密钥进行签名，可以在 ~/.makepkg.conf 中设置 GPGKEY=<identifier>.

如果你想要发布一个软件包，首先将软件包和签名用 scp 拷贝到 orion.archlinux.org 的 staging/community 目录下，然后通过进入 pkgname/trunk 目录并运行 archrelease community-arch 来为 标识 该软件包。这将在 community-i686 或 community-x86_64 目录下创建一份 trunk 条目的 svn 拷贝。这也表示这一软件包已经在所在平台的 [community] 仓库中了。注意 staging 目录与 staging 仓库不一样，所有软件包都需要上传到 staging 目录。可以使用 communitypkg 脚本自动执行这个过程。

注意： 在有些情况下，特别是对于 community 软件包来说，x86_64 的 TU 也许会在 pkgrel 后加上 .1 （不是 +1）。这表示对于 PKGBUILD 的改动是仅限于 x86_64 平台的并且 i686 平台的维护者 不应该 为 i686 平台重建此软件包。如果 TU 想要提升 pkgrel ，那就应该按照通常的方法 +1 。然而，TU 在提升 pkgrel 时，pkgrel=2.1 不应该变为 pkgrel=3.1 而必须应变为 pkgrel=3 。简单的说，就是将 带有点（.） 发行的版本只留给维护 x86_64 平台的 TU 来避免混乱。

软件包更新汇总：

  • 更新 软件包目录 (svn update some-package)
  • 改变当前目录 到软件包的 trunk 目录 (cd some-package/trunk)
  • 编辑 PKGBUILD，做出必要的更改，用 updpkgsums 更新校验和.
  • 编译 软件包：使用 makechrootpkg 或 extra-i686-build/extra-x86_64-build. 必须在 干净的chroot环境 中构建软件包。
  • Namcap PKGBUILD 文件和 pkg.tar.gz 二进制包
  • 使用 communitypkg "commit message" 提交、签名，拷贝并标识 此软件包。这将自动进行下面步骤
    • 将改变 提交 至 trunk (svn commit)
    • 签署 软件包: gpg --detach-sign *.pkg.tar.xz.
    • 将软件包和签名拷贝到 orion.archlinux.org (scp pkgname-ver-rel-arch.pkg.tar.xz *.pkg.tar.xz.sig orion.archlinux.org:staging/community/)
    • 标识 此软件包 ({{ic|archrelease community-{i686,x86_64}}})
  • 更新 软件仓库(ssh orion.archlinux.org /community/db-update)

另外请阅读 Packager Guide 页面的 Miscellaneours 部分和 SSH keys#ssh-agent。对于 Avoid having to enter your password all the time 部分，使用 orion.archlinux.org 而不要使用 gerolde.archlinux.org。

停止维护软件包

如果一个 TU 不想再维护一个软件包了，他应该在 AUR 邮件列表中发出一个通知，以便其他的 TU 可以继续维护该软件包。一个软件包即是在没有其他 TU 维护的情况下仍然能够被一个 TU 停止维护。但是 TU 应该尽量不要放弃放弃很多软件包（他们不应该负责超过他们时间允许的工作）。如果一个软件包已经过时或者不再被使用，那么也应该被完全移除。

如果一个软件包已经被完全移除，它也可以重新上传到 UNSUPPORTED，使得普通用户可以替 TU 维护它。

将软件包从 unsupported 移到 [community]

按照普通的向 community 仓库添加软件包的步骤即可，但是记得将相应的软件包从 unsupported 中移除。

将软件包从 [community] 移至 unsupported

按照上面提到的方法移除软件包，并将你的源代码上传到 AUR 即可。

将软件包从 [community-testing] 移至 [community] 

ssh nymeria.archlinux.org /srv/repos/svn-community/dbscripts/db-move community-testing community package

从 unsupported 删除软件包

没必要移除虚设的软件包，因为他们会在试图跟踪依赖关系时被重新创建。如果有人上传了一个实际的软件包，那么所有依赖的软件包都会指向正确的位置。

TU 辞职需要完成的事项

当一个 TU 辞去自己的职务，而且不再是一个开发者时，需要执行如下操作：

  1. 此 TU 的所有软件包需要被重新签名(重新打包). TU 编译的软件包可以通过下面 URL 从 Archweb 查询 https://archlinux.org/packages/?sort=&q=&packager=$packager&flagged= where packager 替换成 TU 在 Archweb 的用户名.
  2. Archweb 需要禁用此 TU 帐号，并添加到 'Retired Trusted users' 组. 从 'Trusted Users' 移除此 TU，软件仓库权限收回。
  3. 从服务器上禁用此帐号的 shell 访问权限(尤其是 repos.archlinux.org, pkgbuild.com)
  4. 移除此用户的 GPG key，仓库中提交新的 archlinux-keyring 软件包。

另见