PKGBUILD编写的一点体会

athurg

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

axlrose

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

hubert_star

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

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

第七条比较扯了

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

athurg

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

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


欢迎探讨指正！

clinif

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

hubert_star

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

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


欢迎探讨指正！

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

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

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

athurg

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

看上去有点道理。

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

hubert_star

Post by athurg;1948043
看上去有点道理。

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

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

Arne

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