Arch packaging standards (简体中文)

From ArchWiki
Jump to: navigation, search
翻译状态: 本文是英文页面 Arch packaging standards翻译,最后翻译时间:2017-09-04,点击这里可以查看翻译后英文页面的改动。

当为Arch Linux构建软件包时,您应该遵循以下的软件包指导原则,如果您想贡献你的软件包至Arch Linux时,您应该更加遵循软件包指导原则。同时需要阅读PKGBUILDmakepkg 手册。

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文件中去掉空行(没有设置变量值的行)(如providesreplaces等)</li>
  • 通常实践建议按照上文中的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/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 数组应该包含 i686 和/或 x86_64 ,取决于软件可以构建的目标架构。也可以使用 any 生成那些架构无关的包。

授权协议

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

特殊包补充手册

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

Package creation guidelines

CLRCrossEclipseFree PascalGNOMEGoHaskellJavaKDEKernelLispMinGWNode.jsNonfreeOCamlPerlPHPPythonRubyVCSWebWine

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