AUR 提交准则

来自 Arch Linux 中文维基

相关文章

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

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

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

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

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

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

  • 仔细检查上传的文件。编写PKGBUILD前务必阅读 Arch软件打包标准。劣质的 PKGBUILD 会影响软件的正常使用，不要指望别人会因为您糟糕的 PKGBUILD 浪费了他们的时间而收到感谢。
  • 任何提交的 PKGBUILD 都不能编译已经位于官方二进制软件包仓库的程序。如果认为官方仓库的软件包已过期，请标记它。如果它有问题或者缺少功能，请反馈反馈bug报告。
唯一的例外是和官方打包版本相比增加或开启了新的功能或者使用了不同的补丁。这时需要修改 pkgname 来表示新增的功能。例如加入了边栏支持的 screen 应该命名为 screen-sidebar。此外还需要同时添加 conflicts=('screen') 以避免与官方仓库中的包冲突。
  • 检查 AUR 中是否已有相同软件包。如果已经有人维护某软件包，可以以评论的形式将变化报告给维护人员。如果软件包无人维护或不存在，用户提交的软件包将被认领。别创建重复的包。
  • 确保您的软件包有人需要。在提交前请仔细想想：有人会用这个软件包吗？它非常特别吗？如果不是只有少数人觉得它有用，就提交它。
AUR 和官方软件仓库中计划放置通用软件和软件相关的内容，包括：可执行文件、配置文件、软件的在线/离线文档和软件直接使用的媒体数据。
  • 不要在 AUR PKGBUILD 中使用 replaces，除非这个软件包将要被重命名（例如当 Ethereal 变成 Wireshark 时）。如果这个软件包是已经存在的软件包的另一版本，使用 conflicts （或者如果这个软件包被其他软件需要时，使用 provides）。两者的主要区别是：在 pacman 同步（-Sy）之后，如果遇到与 replaces 匹配并已经安装的软件包时，pacman 会立刻想去替换它。而 conflicts 则在安装软件包时进行替换。
  • 请为那些由版本控制系统构建，而不属于任何特定版本的软件包的包名添加合适的后缀，如 -git。具体细则见 VCS 软件打包准则#软件包命名。
  • 如果源代码是可取得的，请避免提交二进制文件。AUR不应当包含 makepkg 创建的二进制包，也不应当包含文件列表。
  • 当源码可获得时，那些预构建可以直接部署的二进制包应该加上 -bin 后缀， Java 除外。除此之外，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 。将公钥导入到用户账户的 My Account 一节，然后为 aur.archlinux.org 指定私钥的位置，例如： 

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

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

$ ssh-keygen -f ~/.ssh/aur
提示：在输入公钥时可以通过换行的方式设置添加多个公钥。

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

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

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

如果您已经有一个软件包了，如果它不是 Git 仓库的话，初始化： 

$ git -c init.defaultBranch=master init

并添加远程 AUR 地址： 

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

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

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

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

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

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

不要仅仅为了更新pkgvar就更新VCS 软件包。当上游有新的提交时，他们不会被视为过时。只有当有其他变化，比如打包流程发生变化时，才应该进行更新。

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

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

例如: 

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "useful commit message"
$ git push
注意：
提示：为了保持工作目录和提交尽可能的干净，可以创建 gitignore(5) 文件来排除所有文件，然后再按需添加文件。

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

  • 阅读其他用户的反馈，并试着听从建议改进软件包，这是个学习的过程！
  • 升级软件包后，不要在评论中加入版本更新信息，这些信息会冲淡更重要的用户评论。
  • 不要提交软件包后就放任不管！检查更新并改进 PKGBUILD 是维护者的责任。
  • 发觉自己不再想维护某个软件包？可以通过 AUR web 界面 disown 一个软件包或是在 AUR 邮件列表发条消息。如果这个包的所有维护者都disown，那么它就会变成一个"orphaned"软件包。
  • 自动化对维护人员来说是有价值的工具，但它不能取代人工干预（例如：项目可能会修改许可证、添加或删除依赖关系，以及其它在「小版本」中的显著更改）。自动更新PKGBUILD的风险将由您自行承担，任何出现问题的账户与他们提交的软件包都可能被无事前通知地删除。

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

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

删除[编辑 | 编辑源代码]

你可以请求 unlist AUR 中的一个pkgbase。提交时请附上原因说明，也可以是其他有用的细节。(比方说其他包提供了相同的东西，或者你就是这个包的维护者，又或者是它被重命名并经过软件包所有者同意，等等)。

注意：
  • 只在软件包的评论区解释原因并不够。当包维护者想要删除时，目前来说唯一有效的方式是在 aur-request 邮件列表中解释。
  • 删除请求可能被否决。比如当这个包的维护者是你时，我们可能会建议你只放弃维护，并允许其他人来维护它。

移除请求需要如下信息（务必用英语）：

  • 简要解释请求删除的原因。注意仅仅在软件包下评论是不足以指出需要删除的原因的。因为在 TU 采取行动之前，aur-requests 是唯一能取得这些信息的地方。
  • 支持删除原因的详细内容，例如这个软件包已经由另一个软件包提供。
  • 移除请求可能会被拒绝。例如如果您是维护者的话，您很有可能被建议 disown 这个软件包，以便让其他打包者认领。
  • 软件包被删除之后，它的 Git 仓库仍然能从 AUR 中被获取。

合并[编辑 | 编辑源代码]

合并请求会删除软件包 base，并将现有的投票数、评论转移到另一个软件包 base 中。将要合并到的软件包 base 是必须的。 这个操作是在例如上游进行了重命名项目时使用的。

注意： 这和 git merge 或者 GitLab 的 merge request 没有任何关系。
  • 由于投票和评论会转移到已经存在的目标中，如果一个包本身没有投票或评论，那么删除并链接到新包效果完全相同。

取消维护权限[编辑 | 编辑源代码]

如果你要求撤销现有维护者对pkgbase的所有权，而该维护者在两周之内没有反应，取消维护权限请求就会通过。另外，如果一个软件被标记为过期超过180天，请求会被自动通过。

检索自“https://wiki.archlinuxcn.org/wzh/index.php?title=AUR_提交准则&oldid=28982”