PKGBUILD编写的一点体会

1、非正式(SVN、git、cvs等)发布包:
这类包最大的问题就是起版本的标识以及命名。
对于版本标识,建议直接用SVN版本号作为pkgver。
对于命名,建议采用“软件名-svn”的方式。
为了解决对应的正式发布包的兼容性问题,以及其他依赖于这个包的软件的非正式发布包的依赖关系。我们建议
1)、加上provides=('软件包=最近的正式发布版本号' '软件包-svn=SVN版本号').
2)、对于依赖非正式发布版本的软件包,我们可以在依赖关系中使用depends=('软件包-svn>SVN版本号')来解决依赖关系。而对于可以依赖正式版本,也可以依赖非正式发布版本的情况,建议优先采用依赖正式发布版depends=('软件包>版本号')

2、软件官方版本号不规则:
在我们的包管理系统中,版本号是由小数点隔开大多组数字组成的。但是有些软件作者常常会采用一些字母(比如xxxrc、xxxalpha)甚至是连字符“-”。对于字母大情况,我们原样保留,对于连字符,需要替换成下划线“_”
然后在此后引用该版本号的时候,使用${pkgver//_/-}来取代${pkgver},即可自动替换为连字符,同时也规范了pkgver的编写

3、进入build函数后,makepkg会自动当前目录切换到src所在的目录,所以不用另加一个cd ${srcdir}

4、可以适当使用系统内置变量(比如PKGBUILD所在目录$startdir、源代码解压缩到的目录$srcdir、编译安装的目标目录(最后打包成软件包的目录)$pkgdir),但不推荐自己定义变量。

5、所有在source组中指定的源文件将会自动复制、链接到$srcdir,如果是压缩文件会自动解压缩到这里,不用做解压的工作。

6、建议在每步操作后面加上“ || return 1”来检查该操作是否正确完成

7、(扯淡,哈哈)软件包描述建议采用中文,软件包名在有官方和民间公认的情况下也可以采用中文,比如Firefox可以用“火狐”

8、如果你需要在软件包卸载的时候备份位于/etc的配置文件,可以在backup=('备份文件名1' '文件名2'),这些文件将会自动重命名为某某某.pacsave

作者: athurg   发布时间: 2009-02-15

收藏,PKGBUILD相对ebuild要容易些,更多的人学习PKGBUILD,贡献到aur的话,有yaourt很方便

作者: axlrose   发布时间: 2009-02-16

第三条,虽然不用加cd ${srcdir},但是标准的压缩包往往都是解压后是一个文件夹的形式,而此时往往就需要在进入build时执行:cd ${srcdir}/${pkgname}-${pkgver}这样的跳转代码,注意到没有,官方所有包在使用cd的时候,往往使用全路径名而很少(除非非常明确的情况下)使用相对路径名。

第四条,如果需要定义额外的东西时,比如补丁版本号什么的,一定要使用自定义的变量将版本号提取到变量定义部分,而不要写在内部固化的版本字符串。所以,要尽量将变化的东西用自定义变量定义,而不要写死在build过程里面

第七条比较扯了

软件包名一定要用英文,而描述最好使用英文,如果描述不清楚的话可以提供两种语言的描述。

作者: hubert_star   发布时间: 2009-02-16

不过我觉得如果不是规律性变化的东西,还是尽量不要自定义变量的好。比如补丁,补丁的名字、版本号命名规律甚至是有无,通常都是有规矩可循,但是无人追寻。

第三条我也在考虑怎么回事儿,因为我觉得在编译过程如果用相对路径便于移植,避免有时候将编译环境的信息带到使用环境中去。


欢迎探讨指正!

作者: athurg   发布时间: 2009-02-16

没写过PKGBUILD,但从使用的过程中让我感觉svn、git、cvs类包的packver字段有点麻烦啊,用yaourt安装老是出错,经常需要手动修改,比如:
http://bbs.archlinux.org/viewtopic.php?id=63439
不知道有啥方法可以彻底解决这个问题?

作者: clinif   发布时间: 2009-02-16

引用:
作者: athurg
不过我觉得如果不是规律性变化的东西,还是尽量不要自定义变量的好。比如补丁,补丁的名字、版本号命名规律甚至是有无,通常都是有规矩可循,但是无人追寻。

第三条我也在考虑怎么回事儿,因为我觉得在编译过程如果用相对路径便于移植,避免有时候将编译环境的信息带到使用环境中去。


欢迎探讨指正!
为什么使用自定义变量,可以这么认为:当所引用的东西多次出现的时候,最好用变量来标示,其实变量用不用对于程序执行没有任何影响,但是如果不用变量而多次出现的话(比如补丁包后面带了个版本号),当版本号变化的时候就需要在多个地方修改,这就是用变量的理由。写程序也是一样的道理,有固定意义的常量定义最好去DEFINE一下,而不是直接用具体的数字。

第三条是分情况的,而且要尤其小心。只是cd是否用全路径名是可以探讨的,至于make install等需要路径的地方,想都不用想,不在第三条的讨论范围之内,哪里需要全路径,哪里需要相对路径,是要有很清晰的认识。比如make install一定要用全路径。

再来谈cd过程,严格来讲,如果一切是可控的话,那么用全路经还是相对路径无所谓。但是如果执行某一过程后不在当前位置了,那么相对路径反而会使问题复杂化。

作者: hubert_star   发布时间: 2009-02-16

引用:
再来谈cd过程,严格来讲,如果一切是可控的话,那么用全路经还是相对路径无所谓。但是如果执行某一过程后不在当前位置了,那么相对路径反而会使问题复杂化。
看上去有点道理。

变量这一点,如果确实有规律可循,不妨也建议用变量。不过要避免和系统内部变量冲突,而系统到底有哪些变量,恐怕很难说清楚。这也是官方在WIKI里建议自定义变量以下划线“_”开头的缘故,如果我没理解错,文章的意思是尽量不用,实在要用就用下划线开头

作者: athurg   发布时间: 2009-02-16

引用:
作者: athurg
看上去有点道理。

变量这一点,如果确实有规律可循,不妨也建议用变量。不过要避免和系统内部变量冲突,而系统到底有哪些变量,恐怕很难说清楚。这也是官方在WIKI里建议自定义变量以下划线“_”开头的缘故,如果我没理解错,文章的意思是尽量不用,实在要用就用下划线开头

相关包或者补丁的版本号(但又与pkgver不同)是很典型的变量应用的地方,但是除此以外,我也没发现哪里有需要用变量的地方。

作者: hubert_star   发布时间: 2009-02-16

反正pkgbuild经常出问题,久而久之就会自己修改了

作者: Arne   发布时间: 2009-02-16