Arch 打包标准 (简体中文)

From ArchWiki

Jump to: navigation, search


i18n
English
Español
Русский
简体中文
繁體中文

Contents

软件包标准

当为Arch Linux构建软件包时,您应该遵循以下的软件包指导原则 , 如果您想贡献你的软件包至Arch Linux时,您应该更加遵循软件包指导原则.

PKGBUILD样例

# Contributor: Your Name <youremail@domain.com>
pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc=""
arch=()
url=""
license=('GPL')
groups=()
depends=()
makedepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=() #generate with 'makepkg -g'

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

  ./configure --prefix=/usr
  make || return 1
  make DESTDIR="$pkgdir" install
}

打包规则

  • 不推荐将软件包安装至/usr/local
  • 在build函数中,在重要的行尽可能的加上 "|| return 1" 以确保改行正确执行。例如:
    patch -Np1 -i ../patchfile.patch || return 1
    make || return 1
    make DESTDIR=$startdir/pkg install || return 1
    	
  • 除非没有就不行,否则绝对不要在你的PKGBUILD中自定义和使用新的变量,以避免和makepkg本身的变量冲突。即便在非用不可的情况下,我们也强烈建议给自定义变量名前加上下划线 (_)。例如:
    _customvariable=

    AUR无法检测自定义变量的使用,所以无法自动替换自定义变量值。通常这种错误发生在source 变量数组上,比如说:

    http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2

    这种情况下AUR是无法正确找到下载位置的。

  • 任何情况下都要避免使用/usr/libexec/,而用/usr/lib/${pkgname}/取代。
  • 在包信息文件中的packager字段可以由包构建者可以修改/etc/makepkg.conf文件中有些选项,以实现自定义。或者在使用makepkg编译包之前,先直接导出PACKAGER变量:
    # export PACKAGER="yourname@your.email"
  • 所有安装过程中所需输出的重要的信息,都可以放到.install 文件中.比如说如果某软件包需要扩展的安装步骤才能正常运行,你可以将这些步骤的介绍包含在.install文件中。
  • 任何运行该软件包不需要,或者该软件包的通用功能不需要的可选的依赖不要加入到depends中,但是要在.install文件中包含相应的提示信息,使之在安装之后输出。比如: "要启用SMB支持,请下载安装Samba 包."
  • 在填写软件包描述(description)时,请不要使用下定义的方式。比如说, "Nedit is a text editor for X11" 就可以简写为"A text editor for X11". 顺便注意保持descriptions在80个字以内.
  • 尽量保持PKGBUILD文件中每行不超过100字符。
  • 如果可能的话, 从PKGBUILD文件中去掉空行(没有设置变量值的行)(如providesreplaces等)
  • 通常实践建议按照上文中的PKGBUILD示例安排各变量顺序。当然这不是强制性的,当然必须满足正确的bash语法.

软件包命名

  • 软件包应当仅包含字母或数字;所有的字母应当保持小写.
  • 软件包版本号应当和作者发行版号保持一致. 如果需要的话,版本号可以包含字母(比如:nmap的版本就是2.54BETA32)。 版本号里不能包含连字符,只能允许字母、数字、下划线、点号。
  • Package releases(软件包发行号) 仅用于特指Arch的软件包. 这就允许在新版包发布的时候,用户选择新旧不同的版本来编译., 发布号从1开始. 然后由于软件包可能被修补, 软件包将会被 重(打包)发布 ,然后发行号将会增加。 当新版本发布的时候,发行号(release)自动回到1。 软件包发布标记和软件包版本标记准从同样的规则.

目录

  • 配置文件应该放置到/etc 目录.如果有多个配置文件,可以使用子目录,以保持/etc 简洁. 即/etc/{pkgname}/{pkgname}代表软件包的名称 (或者其他合适的名称, 比如apache使用的就是/etc/httpd/).
  • 软件包文件应该安装在下列常用目录中:
  • /etc System-essential配置文件
    /usr/bin 应用程序可执行代码(二进制文件)
    /usr/sbin 系统可执行代码(二进制文件)
    /usr/lib 库文件
    /usr/include 头文件
    /usr/lib/{pkg} 模块、插件等
    /usr/share/man 文档手册
    /usr/share/{pkg} 应用程序数据
    /etc/{pkg} {pkg}的单独配置文件
    /opt 大型的独立自包含软件包,比如KDE、Mozilla等
  • 软件包不应该包含安装到下列目录:
    • /dev
    • /home
    • /media
    • /mnt
    • /proc
    • /root
    • /selinux
    • /sys
    • /tmp
    • /var/tmp

Makepkg 的任务

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

  1. 检查软件包的依赖关系的包是否安装
  2. 从服务器中下载源码 文件
  3. 解压 源码文件
  4. 打上必要的 补丁(patch)
  5. 构建 软件并以fake root身份安装
  6. 从软件包中去掉 /usr/doc, /usr/info, /usr/share/doc, and /usr/share/info目录
  7. 从可执行文件中去掉符号标记
  8. 从可执行文件中去掉调试标记
  9. 生成包信息文件(包含软件包的基本信息)
  10. 压缩 fake root成为软件包文件(*.pkg.tar.gz)
  11. 将生成的软件包文件保存在配置的目的目录中(默认在当前目录

架构

arch数组只能包含i686 和(或) x86_64 ,视你构建的目标架构而定。

软件包授权

license数组用于官方仓库中说明软件包的使用授权协议。当然你所制作的包里也可以用。 用法如下:

  • 我们已经在core仓库创建了一个licenses包,以存储常用的授权协议文件。他们被安装在/usr/share/licenses/common。比如/usr/share/licenses/common/GPL.如果软件包的授权符合GPL授权协议,此时license变量就可以直接设置成该目录的名称,即:license=('GPL')
  • 如果liccenses包不包含你的软件包的授权文件,你必须执行以下几步:
    1. 先将授权协议文件放到 /usr/share/licenses/$pkgname/ 下,比如 /usr/share/licenses/dibfoo/COPYING.
    2. 如果源代码不包含授权文件,授权协议文件只在其网站上公布。那么就要先把他复制下来,然后像上面那样放置到指定位置(别忘了给个合适的文件名)。
    3. 将licenses变量设置为 'custom' 。当然你也可以设置为 'custom:"授权类型"'.
  • 一旦某个授权协议在官方仓库(包括[community]仓库)中使用了多次,那该协议应该就很普遍了
  • MIT、BSD、zlib/libpng和Python的授权协议比较特殊。准确说他们不是'通常'所说的授权协议。。由于这几种协议自身规定的可变性,他们这些协议下的每一个软件都可以有他们自己的版权协议。对此我们仍然使用license=MIT之类的写法来定义,同时将软件包自己独立的授权协议放置到/usr/share/licenses/$pkgname/。
  • (此段翻译为译者理解的翻译,未按照原文直译,如果要求较高,建议阅读全文。<译者Athurg注>)
  • 有些包可能在多个授权协议下发布。这种情况下,可以在license变量数组里包含多个说明。比如说: license=("GPL" "custom:一些商业协议")。 对大多数软件包而言,这些授权协议所适用的情况有多种,同种情况下协议间相互抵制. 当pacman分辨这些软件包时,会将双(多)重协议理解成满足其一即可,而且通常情况下会选择GPL或BSD协议,而忽略其他已经列出来的的授权.
  • (L)GPL拥有很多不一样的版本,对于(L)GPL软件,license中的值对应的关系如下:
    • (L)GPL - (L)GPLv2 或其后的版本
    • (L)GPL2 - 仅(L)GPL2
    • (L)GPL3 - (L)GPL3 或其后的版本

提交软件包至AUR

在提交任何软件包到AUR前,请注意以下内容:

  1. 任何情况下,一定不要提交用于编译官方二进制仓库已有软件包的PKGBUILDs ,如果所提交的软件包拥有启用了的扩展特性以及(或者)针对官方包的补丁则例外。如果是这样,应该在pkgname中简单明了表明不同点。比如说:提交一个包含sidebar补丁的screen的PKGBUILD,应该命名为screen-sidebar(或者别的)。 并且在PKGBUILDd provides数组变量中加上('screen'),以表示本软件包和官方的screen冲突。
  2. 为了保证已提交给AUR包的安全,请记住正确填写md5sum字段. md5sum可以用makepkg -g命令生成.
  3. 请在PKGBUILD文件顶部按照下列格式添加一行注释
    # Contributor: Your Name <your.email>
  4. 核实软件包的依赖关系 (例如运行ldd以检测软件包调用的动态链接库). TU团队强烈建议使用Jason Chu (jason@archlinux.org)所写的namcap工具集,来分析你的软件包. namcap将会告诉你错误的权限、缺失/多余的依赖和其他常规错误。你可以使用pacman安装namcap。 记住namcap可以既可以用来检测 pkg.tar.gz 文件,也可以用于PKGBUILDs。
  5. 依赖问题是最常见的打包错误。 Namcap可以协助检测他们,但不一定全对。最好的方法还是查看源代码里面的文档以及程序的发布网站
  6. 在你的PKGBUILD中不要使用replaces,除非你希望重命名你的软件包(。比如Ethereal 更名为Wireshark). 如果你仅仅是提供一个已有版本的更迭版, 使用conflicts (如果该软件包还被其他包依赖的话还有provides ). 主要的不同是: 在同步(-Sy)数据库后,pacman如果遇到含有replace字段的软件包,就会立刻取代已安装的符合replase变量值的软件包,不管他是那个仓库的; 另一方面,conflicts仅仅在你手动安装的时候才会去取代相应的包。(此段翻译不甚准确,读者可参阅原文,有志之士望修正)/li>
  7. 所有上传到AUR的文件应该打包到 压缩的tar包文件中,里面是一个目录,包含着PKGBUILD文件的目录和其他编译所需的添加文件 (补丁,安装文件等)。例如:
    foo/PKGBUILD
    foo/foo.install
    foo/foo_bar.diff
    foo/foo.rc.conf

    压缩包的文件名应该包含软件包的名称,例如:foo.tar.gz

    压缩包不应该包含由makepkg创建的二进制包,也不应该包含到文件列表中

特殊包补充手册

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

CVS/SVN 包

参阅 Arch CVS & SVN PKGBUILD guidelines

Gnome 包

参阅 Gnome package guidelines

Haskell 包

参阅 Haskell package guidelines

Java 包

参阅 Java 打包向导(简体中文)

Lisp 包

参阅 Lisp Package Guidelines

Perl 包

参阅 Perl Package Guidelines

Wine 包

参阅 Arch wine PKGBUILD guidelines

内核模块包

参阅 Kernel Module Package Guidelines

Personal tools