Arch 打包标准 (简体中文)
From ArchWiki
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
文件中去掉空行(没有设置变量值的行)(如provides
、replaces
等) - 通常实践建议按照上文中的
PKGBUILD
示例安排各变量顺序。当然这不是强制性的,当然必须满足正确的bash语法.
软件包命名
- 软件包应当仅包含字母或数字;所有的字母应当保持小写.
- 软件包版本号应当和作者发行版号保持一致. 如果需要的话,版本号可以包含字母(比如:nmap的版本就是2.54BETA32)。 版本号里不能包含连字符,只能允许字母、数字、下划线、点号。
- Package releases(软件包发行号) 仅用于特指Arch的软件包. 这就允许在新版包发布的时候,用户选择新旧不同的版本来编译., 发布号从1开始. 然后由于软件包可能被修补, 软件包将会被 重(打包)发布 ,然后发行号将会增加。 当新版本发布的时候,发行号(release)自动回到1。 软件包发布标记和软件包版本标记准从同样的规则.
目录
-
配置文件应该放置到
/etc
目录.如果有多个配置文件,可以使用子目录,以保持/etc
简洁. 即/etc/{pkgname}/
,{pkgname}
代表软件包的名称 (或者其他合适的名称, 比如apache使用的就是/etc/httpd/
). - 软件包文件应该安装在下列常用目录中:
-
软件包不应该包含安装到下列目录:
- /dev
- /home
- /media
- /mnt
- /proc
- /root
- /selinux
- /sys
- /tmp
- /var/tmp
/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等 |
Makepkg 的任务
当您使用makepkg为您自己构建软件包时,makepkg会自动执行如下功能:
- 检查软件包的依赖关系的包是否安装
- 从服务器中下载源码 文件
- 解压 源码文件
- 打上必要的 补丁(patch)
- 构建 软件并以fake root身份安装
-
从软件包中去掉
/usr/doc
,/usr/info
,/usr/share/doc
, and/usr/share/info
目录 - 从可执行文件中去掉符号标记
- 从可执行文件中去掉调试标记
- 生成包信息文件(包含软件包的基本信息)
- 压缩 fake root成为软件包文件(*.pkg.tar.gz)
- 将生成的软件包文件保存在配置的目的目录中(默认在当前目录)
架构
arch数组只能包含i686 和(或) x86_64 ,视你构建的目标架构而定。
软件包授权
license数组用于官方仓库中说明软件包的使用授权协议。当然你所制作的包里也可以用。 用法如下:
- 我们已经在core仓库创建了一个licenses包,以存储常用的授权协议文件。他们被安装在/usr/share/licenses/common。比如/usr/share/licenses/common/GPL.如果软件包的授权符合GPL授权协议,此时license变量就可以直接设置成该目录的名称,即:license=('GPL')
- 如果liccenses包不包含你的软件包的授权文件,你必须执行以下几步:
- 先将授权协议文件放到 /usr/share/licenses/$pkgname/ 下,比如 /usr/share/licenses/dibfoo/COPYING.
- 如果源代码不包含授权文件,授权协议文件只在其网站上公布。那么就要先把他复制下来,然后像上面那样放置到指定位置(别忘了给个合适的文件名)。
- 将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前,请注意以下内容:
- 任何情况下,一定不要提交用于编译官方二进制仓库已有软件包的PKGBUILDs ,如果所提交的软件包拥有启用了的扩展特性以及(或者)针对官方包的补丁则例外。如果是这样,应该在pkgname中简单明了表明不同点。比如说:提交一个包含sidebar补丁的screen的PKGBUILD,应该命名为screen-sidebar(或者别的)。 并且在PKGBUILDd provides数组变量中加上('screen'),以表示本软件包和官方的screen冲突。
-
为了保证已提交给AUR包的安全,请记住正确填写
md5sum
字段.md5sum
可以用makepkg -g
命令生成. -
请在
PKGBUILD
文件顶部按照下列格式添加一行注释:# Contributor: Your Name <your.email>
-
核实软件包的依赖关系 (例如运行
ldd
以检测软件包调用的动态链接库). TU团队强烈建议使用Jason Chu (jason@archlinux.org)所写的namcap
工具集,来分析你的软件包.namcap
将会告诉你错误的权限、缺失/多余的依赖和其他常规错误。你可以使用pacman
安装namcap
。 记住namcap
可以既可以用来检测 pkg.tar.gz 文件,也可以用于PKGBUILDs。 - 依赖问题是最常见的打包错误。 Namcap可以协助检测他们,但不一定全对。最好的方法还是查看源代码里面的文档以及程序的发布网站
- 在你的PKGBUILD中不要使用replaces,除非你希望重命名你的软件包(。比如Ethereal 更名为Wireshark). 如果你仅仅是提供一个已有版本的更迭版, 使用conflicts (如果该软件包还被其他包依赖的话还有provides ). 主要的不同是: 在同步(-Sy)数据库后,pacman如果遇到含有replace字段的软件包,就会立刻取代已安装的符合replase变量值的软件包,不管他是那个仓库的; 另一方面,conflicts仅仅在你手动安装的时候才会去取代相应的包。(此段翻译不甚准确,读者可参阅原文,有志之士望修正)/li>
-
所有上传到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 包
Haskell 包
Java 包
Lisp 包
Perl 包
Wine 包
参阅 Arch wine PKGBUILD guidelines
内核模块包
参阅 Kernel Module Package Guidelines