Arch package guidelines (简体中文)

翻译状态：本文是 Arch packaging standards 的翻译。上次翻译日期：2018-05-17。如果英文版本有所更改，则您可以帮助同步翻译。

当为Arch Linux构建软件包时，您应该遵循以下的软件包指导原则，尤其当打算贡献软件包至Arch Linux时更是如此。同时需要阅读PKGBUILD 和 makepkg 手册。

PKGBUILD样例

# Maintainer: Your Name <[email protected]>
pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc=""
arch=()
url=""
license=('GPL')
groups=()
depends=()
makedepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
changelog=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=() #autofill using updpkgsums

build() {
  cd "$pkgname-$pkgver"

  ./configure --prefix=/usr
  make
}

package() {
  cd "$pkgname-$pkgver"

  make DESTDIR="$pkgdir/" install
}

可以从 pacman 和 abs 的 /usr/share/pacman 中找到其它原型。

打包规则

永远别将软件包安装至/usr/local
除非没有就不行，否则绝对不要在PKGBUILD中自定义和使用新的变量，以避免和 makepkg 本身的变量冲突。
即便在非用不可的情况下，我们也强烈建议给自定义变量名前加上下划线 (_)。例如：
```
_customvariable=
```
任何情况下都要避免使用/usr/libexec/，应该使用/usr/lib/${pkgname}/。
包信息文件中的packager字段可以通过修改/etc/makepkg.conf文件由编译者进行自定义。使用 ~/.makepkg.conf也可以达到此目的。
所有安装过程中所需输出的重要的信息，都可以放到.install 文件中.比如说如果某软件包需要扩展的安装步骤才能正常运行，你可以将这些步骤的介绍包含在.install文件中。
Dependencies 是最容易出现错误的地方。请花时间仔细核对，例如对动态可执行文件执行 ldd，检查脚本需要的工具，查看软件文档等。namcap PKGBUILD 和生成的打包文件，报告权限错误、缺少依赖、过多依赖等常见问题。
任何运行该软件包不需要，或者该软件包的通用功能不需要的可选的依赖不要加入到depends中，这些信息应该加入optdepends 数组，例如：

optdepends=('cups: printing support'
            'sane: scanners support'
            'libgphoto2: digital cameras support'
            'alsa-lib: sound support'
            'giflib: GIF images support'
            'libjpeg: JPEG images support'
            'libpng: PNG images support')

例子取自 extra 中的 wine 软件包。这些信息在安装和升级时会自动打印，所以不要将这些信息加入 .install 文件。

在填写软件包描述（description）时，请不要使用下定义的方式。比如说, "Nedit is a text editor for X11" 就可以简写为"A text editor for X11". 顺便注意保持descriptions在80个字符以内.
尽量保持PKGBUILD文件中每行不超过100字符。
如果可能的话, 从PKGBUILD文件中去掉空行（没有设置变量值的行）(如provides、replaces等)
通常实践建议按照上文中的PKGBUILD示例安排各变量顺序。当然这不是强制性的，这里唯一强制要求的是满足正确的bash语法。
变量名可能包含空格时，请使用引号，例如"$pkgdir" 和 "$srcdir".
请确保软件包的完整性，确保校验变量包含正确的数值，可以通过 updpkgsums 工具进行更新。

软件包命名

软件包应当仅包含字母或数字以及@, ., _, +, -，不能以 - 和 . 开头，所有的字母应当保持小写.
软件包的名称不应该包含上游的主版本号，例如如果上游软件包是 libfoo v2.3.4，不应该命名为 libfoo2。这样在上游发布新的大版本时，就可以保留软件包名和依赖可以保持不变。只有个别软件包是例外，例如图形库 GTK 和 Qt。这些软件升级后，应用程序需要花很长时间和经历才能移植完成，所以系统需要同时安装多个版本，软件包名应该包含大版本号，比如 gtk2, gtk3, qt4, qt5. 如果出现大部分软件包都可以同步升级，只有个别软件没有被移植的情况，可以把老的软件包命名为 libfoo1，而新的软件包继续使用 libfoo。
软件包版本号应当和作者发行版号保持一致. 如果需要的话，版本号可以包含字母（比如：nmap的版本就是2.54BETA32）。版本号里不能包含连字符，只能允许字母、数字、下划线、点号。
Package releases（软件包发行号） 仅和 Arch 相关. 这样用户就可以区分不同的编译版本。发布号从1开始,软件包将会被重新（打包）发布时，发行号将会增加1。当新版本发布的时候，发行号（release）自动回到1。软件包发布标记和软件包版本标记遵从同样的规则。

`/etc`	系统关键配置文件
`/usr/bin`	二进制文件
`/usr/lib`	库
`/usr/include`	头文件
`/usr/lib/{pkg}`	模块，插件等
`/usr/share/doc/{pkg}`	应用程序文档
`/usr/share/info`	GNU Info 系统文件
`/usr/share/man`	手册
`/usr/share/{pkg}`	程序数据
`/var/lib/{pkg}`	应用持久数据
`/etc/{pkg}`	`{pkg}`的配置文件
`/opt/{pkg}`	大的独立程序，例如 Java

软件包不应该在下面目录添加任何文件:
- /bin
- /sbin
- /dev
- /home
- /srv
- /media
- /mnt
- /proc
- /root
- /selinux
- /sys
- /tmp
- /var/tmp
- /run

Makepkg 的任务

当您使用makepkg为您自己构建软件包时，makepkg会自动执行如下功能:

检查软件包的依赖和构建依赖是否安装
从服务器中下载源码文件
校验源码文件的完整性
解压源码文件
打上必要的 补丁（patch）
构建软件并以fake root身份安装
从可执行文件中去掉符号标记
从可执行文件中去掉调试标记
Compresses manual and, or info pages
生成包信息文件（包含软件包的基本信息）
压缩 fake root成为软件包文件（*.pkg.tar.xz）
生成的软件包文件保存在配置的目的目录中（默认在当前目录）

架构

如果该软件包是针对特定架构编译的，那么 arch 数组应该包含 x86_64 ，否则使用 any 生成那些架构无关的包。

授权协议

请参考 PKGBUILD (简体中文)#license

特殊包补充手册

请先阅读上面的手册—— 大多数的重点内容都在此页上面部分列出来了，他们将不会在下面这些手册中重复出现。这些特殊的手册是为了作为一些特殊类型的包的补充手册，而不是取代本手册。

Arch 软件包准则

32-bit – CLR – CMake – Cross – DKMS – Eclipse – Electron – Font – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – VCS – Web – Wine

提交到 AUR 的软件包必须额外满足 AUR 提交守则.