AUR 提交准则
用户可以通过 AUR 分享 PKGBUILD 脚本。AUR 中不包含任何二进制包,仅包含用户上传的 PKGBUILD
,供其他用户下载使用。这些 PKGBUILD
都是非官方的,没有经过完整审查,使用风险自担。
提交软件包[编辑 | 编辑源代码]
如果在反复阅读该章节后仍不清楚软件包或构建/提交流程是否正确,可以将自己的 PKGBUILD
贴到 AUR 邮件列表、 论坛 AUR 版、中文论坛 AUR/ABS/PKGBUILD 版或 IRC 频道,让大家帮您检查。
提交软件包的规则[编辑 | 编辑源代码]
提交软件包时请遵循下列的规则:
- 任何提交的
PKGBUILD
都不能编译已经位于官方二进制软件包仓库的程序。可通过官方软件包数据库进行查找,如果在其中发现了任意版本的程序,就不要进行提交。如果认为官方仓库的软件包已过期,请标记它。如果它有问题或者缺少功能,请反馈反馈 bug 报告。
- 唯一的例外是和官方打包版本相比增加或开启了新的功能或者使用了不同的补丁。这时需要修改
pkgname
来表示新增的功能。例如加入了边栏支持的 GNU screen(screen
)应该命名为screen-sidebar
。此外还需要同时添加conflicts=('screen')
以避免与官方仓库中的包冲突。
- 检查 AUR 中是否已有相同软件包。如果已经有人维护某软件包,可以以评论的形式将更改报告给维护人员。如果软件包无人维护或维护者无反馈,可以按需将其认领并更新。不要创建重复的包。
- 确保您的软件包有人需要。在提交前请仔细想想:有人会用这个软件包吗?它非常特别吗?如果不是只有少数人觉得它有用,就提交它。
- AUR 和官方软件仓库是用于放置通用软件和软件相关的内容的,包括:可执行文件、配置文件、软件的在线/离线文档和软件直接使用的媒体数据。
- 不支持
x86_64
架构的软件包不允许上传到 AUR。
- 不要在 AUR
PKGBUILD
中使用replaces
,除非这个软件包将要被重命名(例如当 Ethereal 变成 Wireshark 时)。如果这个软件包是已经存在的软件包的另一版本,使用conflicts
(或者如果这个软件包被其他软件需要时,使用provides
)。两者的主要区别是:在 pacman 同步(-Sy)之后,如果遇到与replaces
匹配并已经安装的软件包时,pacman 会立刻想去替换它。而conflicts
则在安装软件包时进行替换。
- 请为那些由版本控制系统构建,而不属于任何特定版本的软件包的包名添加合适的后缀,如
-git
。具体细则见 VCS 软件打包准则#软件包命名。
- 从特定版本的源码构建的包不应该添加后缀。
- 请按照以下格式在
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 密钥。将公钥导入到用户账户的 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.
pkgbase
与被删除的软件包相同,那克隆下来的仓库会不为空。如果您已经有一个软件包了,但不是 Git 仓库的话,需要进行初始化:
$ git -c init.defaultBranch=master init
并添加远程 AUR 地址:
$ git remote add label ssh://aur@aur.archlinux.org/pkgbase.git
然后向远程仓库拉取以在 AUR 进行初始化。
pkgbase
匹配到已删除软件包的冲突问题。提交和更新软件包[编辑 | 编辑源代码]
git config user.name [...]
和 git config user.email [...]
编辑自己的本地身份!git config user.name "..."
和 git config user.email "..."
对单个包进行修改。当释出新版本的软件时,更新 pkgver 或者 pkgrel 变量来提示所有的用户更新。如果仅仅是对 PKGBUILD 的小修改(例如修正笔误),请不要更新这些变量。
不要仅仅为了更新 pkgver
就更新 VCS 软件包。当上游有新的提交时,他们不会被视为过时。只有当有其他变化,比如打包流程发生变化时,才应该进行更新。
无论何时 PKGBUILD
的元数据发生变动(例如更新了 pkgver()
),都需要重新生成 .SRCINFO。否则 AUR 不会显示更新后的版本号。
要上传或者更新一个软件包,至少要添加 PKGBUILD
和 .SRCINFO
和其它所有新增的或者修改过的辅助文件(例如 .install 文件或者如软件包补丁之类的本地源码文件),写上有意义的提交信息并提交,最后推送这些变动到 AUR 上。
例如:
$ makepkg --printsrcinfo > .SRCINFO $ git add PKGBUILD .SRCINFO $ git commit -m "useful commit message" $ git push
维护软件包[编辑 | 编辑源代码]
- 阅读其他用户的反馈,并试着听从建议改进软件包,这是个学习的过程!
- 升级软件包后,不要在评论中加入版本更新信息,这些信息会冲淡更重要的用户评论。
- 不要提交软件包后就放任不管!检查更新并改进
PKGBUILD
是维护者的责任。 - 发觉自己不再想维护某个软件包?可以通过 AUR 网页界面
disown
一个软件包并/或是在 AUR 邮件列表发条消息。如果这个包的所有维护者都 disown,那么它就会变成一个“orphaned”软件包。 - 自动化对维护人员来说很有用,但它不能取代人工干预(例如:项目可能会修改许可证、添加或删除依赖关系,以及其它的显著更改)。自动更新
PKGBUILD
的风险将由您自行承担,任何出现问题的账户与他们提交的软件包都可能被无事前通知地删除。
请求[编辑 | 编辑源代码]
删除、合并、取消维护权限请求可以通过右侧“Package actions”的“File Request”链接执行。这会给当前的维护者和 aur-requests 邮件列表自动发送邮件通知,之后软件包维护者会接受或拒绝请求。
删除[编辑 | 编辑源代码]
你可以请求 unlist AUR 中的一个 pkgbase
。提交时请附上原因说明(务必用英语),也可以是其它有用的细节(比方说其它包提供了相同的东西,或者如果你就是这个包的维护者,需要重命名且软件包所有者同意,等等)。
合并[编辑 | 编辑源代码]
合并请求会删除 pkgbase
,并将现有的投票数、评论转移到另一个 pkgbase
中。需要用到目标软件包的名称。
这个操作适用于上游进行了重命名项目等情况。
撤销所有权(orphan)[编辑 | 编辑源代码]
要求撤销当前维护者对 pkgbase
的所有权。如果现有维护者在两周之内没有响应,请求就会通过。另外,如果一个软件被标记为过期超过 180 天,请求会被自动通过。