Arch package guidelines (简体中文)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
当为Arch Linux构建软件包时，您应该遵循以下的软件包指导原则，尤其当打算贡献软件包至Arch Linux时更是如此。同时需要阅读PKGBUILD 和 makepkg 手册。
PKGBUILD样例
# Maintainer: Your Name <youremail@domain.com>
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". - 请确保软件包的完整性，确保 校验变量 包含正确的数值，可以通过 {ic|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目录.如果有多个配置文件，可以使用子目录，以保持 /etc 简洁. 即 /etc/{pkgname}/，{pkgname}代表软件包的名称 (或者其他合适的名称, 比如apache使用的就是/etc/httpd/).
- 软件包文件应该安装在下列 常用目录:
/etc系统关键配置文件 /usr/bin二进制文件 /usr/lib库 /usr/include头文件 /usr/lib/{pkg}模块，插件等 /usr/share/doc/{pkg}应用程序文档 /usr/share/infoGNU 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 生成那些架构无关的包。
授权协议
特殊包补充手册
请先阅读上面的手册—— 大多数的重点内容都在此页上面部分列出来了，他们将不会在下面这些手册中重复出现。这些特殊的手册是为了作为一些特殊类型的包的补充手册，而不是取代本手册。
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 提交守则.