AUR 提交准则

用户可以通过 Arch User Repository 分享 PKGBUILD。AUR 中不包含任何二进制包，仅包含用户上传的 PKGBUILD，供其他用户下载使用。所有软件包都是非官方的，使用风险自担。

提交软件包[编辑 | 编辑源代码]

警告： 在提交前请先熟悉 Arch packaging standards 及所有的"相关文章"。违反相应规则的软件包可能不经警告被直接删除。

如果对自己的 PKGBUILD 缺乏信心，可以先把它贴到AUR 邮件列表，论坛 AUR 版或 IRC 频道，让大家帮您检查。

提交软件包的规则[编辑 | 编辑源代码]

提交软件包时请遵循下列的规则:

仔细检查上传的文件。编写PKGBUILD前务必阅读 Arch软件打包标准。劣质的 PKGBUILD 会影响软件的正常使用，不要指望别人会因为您糟糕的 PKGBUILD 浪费了他们的时间而收到感谢。
任何提交的 PKGBUILD 都不能编译已经位于官方二进制软件包仓库的程序。如果认为官方仓库的软件包已过期，请标记它。如果它有问题或者缺少功能，请反馈 bug 报告。

唯一的例外是和官方打包版本相比增加或开启了新的功能或者使用了不同的补丁。这时需要修改 pkgname 来表示新增的功能。例如加入了边栏支持的 screen 应该命名为 screen-sidebar。此外还需要同时添加 provides=('screen') 以避免与官方仓库中的包冲突。

检查 AUR 中是否已有相同软件包。如果已经有人维护某软件包，可以以评论的形式将变化报告给维护人员。如果软件包无人维护或不存在，用户提交的软件包将被认领。别创建重复的包。
确保您的软件包有人需要，有人会用这个软件包吗？它非常特别吗？如果有一些人觉得它有用，就提交它。

AUR 和官方软件仓库中计划放置通用软件和软件相关的内容，包括：可执行文件、配置文件、软件的在线/离线文档和软件直接使用的媒体数据。

不要在 AUR PKGBUILD 中使用 replaces，除非这个软件包将要被重命名（例如当 Ethereal 变成 Wireshark 时）。如果这个软件包是已经存在的软件包的另一版本，使用 conflicts （或者如果这个软件包被其他软件需要时，使用 provides）。两者的主要区别是：在 pacman 同步（-Sy）之后，如果遇到与 replaces 匹配并已经安装的软件包时，pacman 会立刻想去替换它。而 conflicts 则在安装软件包时进行替换。
如果源代码是可取得的，请避免提交二进制文件。AUR不应当包含 makepkg 创建的二进制包，也不应当包含文件列表。
请在 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>

认证[编辑 | 编辑源代码]

要向 AUR 写入软件包，用户需要创建一个 SSH key 。将公钥导入到用户账户的我的帐号一节，然后为 aur.archlinux.org 指定私钥的位置，例如：

~/.ssh/config

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

建议为 AUR 创建一个新的密钥（而不是用旧的），这样出问题时可以直接废除密钥：

$ ssh-keygen -f ~/.ssh/aur

提示：在输入公钥时可以通过换行的方式设置添加多个公钥。

创建软件包仓库[编辑 | 编辑源代码]

如果您正在创建新的软件包，请通过克隆所需的 pkgbase 的方式建立一个远程 AUR 仓库和本地 Git 仓库。如果软件包还不存在，则会出现以下预料之中的警告：

$ git clone ssh://aur@aur.archlinux.org/pkgbase.git

Cloning into 'pkgbase'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

注意： 即使 AUR 中的软件包被删除 Git 仓库也不会删除，所以您可能会发现 clone 一个 AUR 中还不存在的软件包时不会看到这个警告。

如果您已经有一个软件包了，如果它不是 Git 仓库的话，初始化并添加远程 AUR 地址：

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

然后从远程获取文件并初始化。

提示：使用推送和变基来解决 pkgbase 匹配到已删除软件包的冲突问题。

提交和更新软件包[编辑 | 编辑源代码]

警告： 不想以全局身份提交？记得通过 git config user.name [...] 和 git config user.email [...] 编辑自己的本地身份！

当释出新版本的软件时，更新 pkgver 或者 pkgrel 变量来提示所有的用户更新。如果仅仅是对 PKGBUILD 的小修改（例如修正笔误），请不要更新这些变量。

无论何时 PKGBUILD 的元数据发生变动（例如更新了 pkgver()），都需要重新生成 .SRCINFO 。否则AUR不会显示更新后的版本号。

要上传或者更新一个软件包，至少要添加 PKGBUILD 和 .SRCINFO 和其他所有新增的或者修改过的辅助文件（例如 .install 文件或者如补丁之类的本地源码文件），提交，最后推送这些变动到AUR上。

例如:

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "useful commit message"
$ git push

注意： 如果您忘记在首次提交中包含 .SRCINFO，您可以使用 rebasing with --root 或是 filtering the tree 使得 AUR 接受您的第一次推送

提示：为了保持工作目录和提交尽可能的干净，可以创建 gitignore(5) 文件来排除所有文件，然后再按需添加文件。

维护软件包[编辑 | 编辑源代码]

阅读其他用户的反馈，并试着听从建议改进软件包，这是个学习的过程！
升级软件包后，不要在评论中加入版本更新信息，这些信息会冲淡更重要的用户评论。
不要提交软件包后就放任不管！检查更新并改进 PKGBUILD 是维护者的责任。
发觉自己不再想维护某个软件包？可以通过 AUR web 界面 disown 一个软件包或是在 AUR 邮件列表发条消息。如果这个包的所有维护者都disown，那么它就会变成一个 “orphaned” 软件包.

其他事项[编辑 | 编辑源代码]

取消维护权限、删除、合并请求可以通过右侧 "Package actions" 的 "File Request" 链接执行。这会给当前的维护者和 aur-requests 邮件列表自动发送邮件通知。Trusted Users 会接受或拒绝请求。

如果现在的维护者在两周之内没有反应，orphan 请求就会通过。
合并请求会删除软件包 base，并将现有的投票数、评论转移到另一个软件包 base 中。将要合并到的软件包 base 是必须的。请注意这和 git merge 或者 GitLab 的 merge request 没有任何关系。
移除请求需要如下信息（务必用英语）：
- 简要解释请求删除的原因。注意仅仅在软件包下评论是不足以指出需要删除的原因的。因为在 TU 采取行动之前，aur-requests 是唯一能取得这些信息的地方。
- 支持删除原因的详细内容，例如这个软件包已经由另一个软件包提供。
- 移除请求可能会被拒绝。例如如果您是维护者的话，您很有可能被建议 disown 这个软件包，以便让其他打包者认领。
- 软件包被删除之后，它的 Git 仓库仍然能从 AUR 中被获取。