AUR 提交指南

来自 ArchWiki

相关文章

用户可以使用 Arch 用户仓库 来分享 PKGBUILD 脚本。它不包含任何二进制软件包，但允许用户上传可以被其他人下载的 PKGBUILD。这些 PKGBUILD 是完全非官方的，并且未经彻底审查，因此使用它们需要您自担风险。

提交软件包

警告： 在尝试提交软件包之前，您应该熟悉 Arch 打包标准 以及“相关文章”下的所有文章。仔细验证 您上传的内容是否正确。违反规则 的软件包可能会在没有警告的情况下被删除。

如果您在阅读本节两遍后，仍然对软件包或构建/提交过程有任何不确定之处，请将 PKGBUILD 提交到 AUR 邮件列表、Arch 论坛上的 AUR 论坛，或者在我们的 IRC 频道 上寻求公开审查，然后再将其添加到 AUR。

提交规则

当向 AUR 提交软件包时，请遵守以下规则

  • 提交的 PKGBUILD 绝不能构建任何官方二进制仓库中已有的应用程序。请检查 官方软件包数据库 中是否已存在该软件包。如果任何版本存在，请勿提交该软件包。如果官方软件包已过期，请将其标记为过期。如果官方软件包已损坏或缺少某个功能，请提交错误报告。
此严格规则的例外情况可能仅限于与官方软件包相比，启用了额外功能和/或包含补丁的软件包。在这种情况下，pkgname 应该有所不同以表达这种差异。例如，包含侧边栏补丁的 GNU screen 软件包可以命名为 screen-sidebar。此外，应使用 conflicts=('screen') 数组以避免与官方软件包冲突。
  • 检查 AUR 以查看软件包是否已存在。如果当前有人维护，可以在评论中提交更改以引起维护者的注意。如果软件包无人维护或维护者没有回应，则可以采纳该软件包并根据需要进行更新。请勿创建重复的软件包。
  • 确保您要上传的软件包是有用的。是否有人会想使用此软件包？它是否过于专业化？如果有多人会觉得此软件包有用，则适合提交。
AUR 和官方仓库旨在用于安装通用软件和与软件相关的内容的软件包，包括以下一项或多项：可执行文件；配置文件；特定软件或整个 Arch Linux 发行版的在线或离线文档；旨在直接被软件使用的媒体。
  • AUR 不允许 不支持 x86_64 架构的软件包。
  • 除非软件包要重命名，例如 Ethereal 变为 Wireshark 时，否则请勿在 AUR PKGBUILD 中使用 replaces。如果软件包是已存在软件包的替代版本，请使用 conflicts（以及 provides，如果其他软件包需要它）。主要区别在于：在同步 (-Sy) 后，pacman 会立即想要替换已安装的“冲突”软件包，只要在任何仓库中遇到具有匹配 replaces 的软件包；另一方面，conflicts 仅在实际安装软件包时才进行评估，这通常是期望的行为，因为它侵入性较小。
  • 从版本控制系统构建且未绑定到特定版本的软件包需要具有适当的后缀，git 使用 -git 等等，有关完整列表，请参阅 VCS 软件包指南#软件包命名。
  • 当源代码可用时，使用预构建 交付件 构建的软件包必须使用 -bin 后缀。 Java 是一个例外。AUR 不应包含 makepkg 创建的二进制 tarball，也不应包含文件列表。
  • 使用特定版本从源代码构建的软件包不使用后缀。
  • 请在 PKGBUILD 文件的顶部添加注释行，其中包含有关当前维护者和先前贡献者的信息，并遵守以下格式。请记住伪装您的电子邮件以防止垃圾邮件。其他行是可选的。
注意： 当涉及电子邮件地址时，使用混淆处理会使人们难以与您联系。
如果您要承担现有 PKGBUILD 的维护者角色，请像这样在顶部添加您的姓名
# Maintainer: Your Name <address at domain dot tld>
如果之前有维护者，请将其作为贡献者。如果您不是原始提交者，则同样适用。如果您是共同维护者，也请添加其他当前维护者的姓名。
# Maintainer: Your name <address at domain dot tld>
# Maintainer: Other maintainer's name <address at domain dot tld>
# Contributor: Previous maintainer's name <address at domain dot tld>
# Contributor: Original submitter's name <address at domain dot tld>
  • 将 LICENSE 文件添加到您的仓库。我们鼓励您在 0BSD 许可证 下许可您的提交。您可以从 RFC 0040 复制 许可证文本。缺少许可证或包含与 0BSD 不同的许可证的软件包 没有资格 晋升为官方仓库。

身份验证

要获得 AUR 的写入权限，您需要拥有一个 SSH 密钥对。公钥的内容需要复制到我的账户中的个人资料中，并且为 aur.archlinux.org 主机配置相应的私钥。例如

~/.ssh/config
Host aur.archlinux.org
  IdentityFile ~/.ssh/aur
  User aur

您应该创建一个新的密钥对，而不是使用现有的密钥对，这样您可以在发生某些事情时有选择地撤销密钥

$ ssh-keygen -f ~/.ssh/aur
提示： 您可以通过在输入字段中用换行符分隔多个公钥，将多个公钥添加到您的个人资料中。

创建软件包仓库

如果您要从头创建新软件包，请通过克隆 预期的 pkgbase，建立本地 Git 仓库和一个 AUR 远程仓库。如果软件包尚不存在，则会显示以下警告

$ git -c init.defaultBranch=master clone ssh://aur@aur.archlinux.org/pkgbase.git
Cloning into 'pkgbase'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.
注意： 如果 pkgbase 与 已删除 的软件包匹配，则仓库将不会为空。

如果您已经有一个软件包，请将其初始化为 Git 仓库（如果它不是）。

$ git -c init.defaultBranch=master init

并添加一个 AUR 远程仓库

$ git remote add label ssh://aur@aur.archlinux.org/pkgbase.git

然后 获取 此远程仓库以在 AUR 中初始化它。

注意： 如果 pkgbase 与已删除的软件包匹配，请 拉取并变基 以解决冲突。

发布新的软件包内容

警告： 您的提交将使用您的 全局 Git 名称和电子邮件地址 进行署名。推送提交后很难更改提交 (FS#45425)。如果您想使用不同的凭据推送到 AUR，您可以为每个软件包使用 git config user.name "..." 和 git config user.email "..." 来更改它们。

当发布软件包软件的新版本时，请更新 pkgver 或 pkgrel 变量，以通知所有用户需要升级。如果仅发布对 PKGBUILD 的微小更改（例如更正错别字），请勿更新这些值。

不要为 VCS 软件包 提交仅 pkgver 版本号提升的提交。当上游有新提交时，它们不被视为已过期。仅当引入其他更改（例如更改构建过程）时才进行新提交。

请务必在 PKGBUILD 元数据更改时重新生成 .SRCINFO，例如 pkgver() 更新；否则 AUR 将不会显示更新的版本号。

要上传或更新软件包，添加 至少 PKGBUILD 和 .SRCINFO，然后添加任何其他新的或修改的辅助文件（例如 .install 文件或 本地源文件，例如 补丁），使用有意义的提交消息 提交，最后将更改 推送 到 AUR。

例如

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "useful commit message"
$ git push
注意
  • 如果 .SRCINFO 未包含在您的上次提交中，请通过使用 git commit --amend 修改您的上次提交 来添加它，以便 AUR 允许您的推送。
  • AUR 仅允许推送到 master 分支。如果本地分支被命名为其他名称，请 重命名它 并再次推送。
提示： 为了尽可能保持工作目录和提交的整洁，创建一个 gitignore(5)，排除所有文件并根据需要强制添加文件。

维护软件包

  • 查看来自其他用户的反馈和评论，并尝试采纳他们提出的任何改进建议；将其视为一个学习过程！
  • 请不要在每次更新软件包时都留下包含版本号的评论。这使评论部分可以用于上面提到的有价值的内容。
  • 请不要只是提交软件包然后就忘记它！维护者的工作是维护软件包，方法是检查更新并改进 PKGBUILD。
  • 如果您因某种原因不想继续维护软件包，请使用 AUR Web 界面 disown 软件包，和/或向 AUR 邮件列表发布消息。如果 AUR 软件包的所有维护者都放弃了它，它将变成一个 “孤立” 的软件包。
  • 自动化是维护人员的宝贵工具，但它不能取代 人工干预（例如，项目可能会更改许可证、添加或删除依赖项，以及其他值得注意的更改，即使是“次要”版本）。自动化 PKGBUILD 更新的风险由您自行承担，任何功能异常的帐户及其软件包都可能在没有事先通知的情况下被删除。

请求

可以通过单击右侧“软件包操作”下的“提交请求”链接来创建删除、合并和孤立请求。这会将通知电子邮件发送给当前的软件包维护者和 aur-requests 邮件列表 进行讨论。 软件包维护者 然后将接受或拒绝该请求。

删除

请求从 AUR 取消列出 pkgbase。需要简短说明删除原因的注释，以及支持详细信息（例如，当软件包由另一个软件包提供时，如果您是维护者本人，它将被重命名并且原始所有者同意等）。

注意
  • 仅在其评论中解释为什么要删除软件包是不够的：一旦软件包维护者采取行动，唯一可以获得此类信息的地方是 aur-requests 邮件列表。
  • 删除请求可能会被拒绝，在这种情况下，如果您是维护者，则可能会建议您放弃软件包，以便其他维护者可以采纳。
  • 在软件包被“删除”后，其 git 仓库仍然可用于 克隆。

合并

请求删除 pkgbase 并将其投票和评论转移到另一个 pkgbase。需要合并到的软件包名称。

例如，如果上游 重命名了他们的项目，则应使用此操作。

注意
  • 这与 git merge 或 GitLab 的合并请求无关。
  • 由于投票和评论的转移需要已存在的目的地，如果软件包没有投票或评论，则删除请求链接到新软件包是相同的。

孤立软件包

请求放弃 pkgbase 的所有权。如果当前维护者在两周内没有回应，这些请求将被批准。例外情况是，如果软件包被标记为过时至少 180 天；孤立软件包请求将自动被接受。

摘自“https://wiki.archlinux.org.cn/index.php?title=AUR_submission_guidelines&oldid=822050”