cuihao->blog

总结一些以前疑惑的关于PKGBUILD的问题。

1. 就算需要，base-devel组中的软件包也不会写入编译时依赖列表（makedepends）：

base-devel软件包组包含编译软件所需的基本工具（软件包列表：i686，x86_64），包括gcc编译器、make之类的。一般编译软件包都需要这些包，所以干脆就规定makedepends中不需要指定它们。

如果你发现怎么makepkg都编译不了，先看看是不是忘记装base-devel了（pacman -S base-devel）。

2. 从git、svn、cvs、hg等版本控制系统获取代码的软件包，版本号会自动更新：

从版本控制系统获取代码的话，只要PKGBUILD是标准格式，版本号会自动更新，以反映最新的代码变化。

比如，从AUR上下载的ibus-git的PKGBUILD，本来的版本号是20110501，可makepkg之后得到的版本号就变成当天日期YYYYMMDD了。

svn、hg版本号会更新为最新修订号，git、cvs用当天的日期了。

3. install文件之作用：

某些软件包除了PKGBUILD，还会附带一个XXX.install文件。这个文件定义了安装、升级、删除软件包前后要执行的操作。

这些操作放到PKGBUILD是不行的，因为最终要安装的是软件包，而非PKGBUILD。

比如，字体软件包安装或卸载后需要刷新字体缓存，这些操作就必须放在install文件中。

4. arch=('x86_64' 'i686') 与 arch=('any') 的区别：

arch=('x86_64' 'i686')表示：该PKGBUILD可以为x86_64和i686平台生成软件包，但生成的软件包并不能跨平台。

而arch=('any')表示：该PKGBUILD生成的软件包在x86_64和i686平台都可以安装。

5. package() 和 build() 函数的区别：

package()是在fakeroot环境执行的，所以能使用某些特殊命令。

其实，通常情况下，把编译过程放在package()、或是把所有操作都放在build()都是可以的。makepkg只保证package()在build()（以及不常见的check()）之后执行。

6. “xxx || return 1”中“return 1”的作用：

“xxx || return 1”的意思是：如果 xxx 命令出错退出了，就退出当前函数并返回错误代码1。这是为了保证重要过程出错时makepkg及时停止。

估计是历史遗留，现在用处不大，因为makepkg本来就会自动出错停止。

7. makepkg不会自动删除旧的src目录，可能导致第二次编译错误：

在执行过一次makepkg的目录再次执行makepkg，src目录不会自动被删除。如果有patch之类的操作，可能因为上次patch过而导致错误。需要手动删除src目录。

想搞一个Arch软件仓库。没钱买服务器，就想着扔到个代码托管网站。本来想用google code，结果SVN总是连不上，最后在github弄了个：pakkuman 。

Arch的软件仓库构造简单，所以放git上也没啥难的。速度还不错，起码能达到100KB/s（以前github慢死了，现在好多了）。

目前没啥特色，主要是验证一下想法。

pacman.conf：

[pakkuman]
Server = https://raw.github.com/cuihaoleo/pakkuman/master/$arch

目前的软件包（随便找了几个以前编译的）：

cuihao@cuihao-arch ~ $ pacman -Sl pakkuman
pakkuman amule-dlp-hg 20111016-1 [已安装]
pakkuman freetype2-git-infinality 2.4.99.git20111130-1 [已安装]
pakkuman gtkqq-git 20111226-1 [已安装]
pakkuman ibus-cloud-pinyin-svn 148-1 [已安装]
pakkuman python-webqq-svn 15-1 [已安装]