cuihao->blog

无意中在最新的 pacman 4.0.1 里面发现了repo-elephant这么个玩意儿。

哦呵呵：

cuihao@cuihao-arch /tmp $ repo-elephant -q
    _    _
   / \__/ \_____
  /  /  \  \    `\
  )  \''/  (     |\
  `\__)/__/'_\  / `
     //_|_|~|_|_|
     ^""'"' ""'"'

啊哈：

cuihao@cuihao-arch /tmp $ repo-elephant -q
     __
    '. \
     '- \
      / /_         .---.
     / | \\,.\/--.//    )
     |  \//        )/  /
      \  ' ^ ^    /    )____.----..  6
       '.____.    .___/            \._)
          .\/.                      )
           '\                       /
           _/ \/    ).        )    (
          /#  .!    |        /\    /
          \  C// #  /'-----''/ #  /
       .   'C/ |    |    |   |    |mrf  ,
       \), .. .'OOO-'. ..'OOO'OOO-'. ..\(,

貌似是个正经玩意儿：

cuihao@cuihao-arch /tmp $ repo-elephant -h
repo-elephant (pacman) 4.0.1

  -q, --quiet       最小化输出信息
  -s, --sign        更新后使用 GnuPG 签名数据库
  -k, --key <密匙>   使用指定的密匙签名该数据库
  -v, --verify      更新前验证数据库签名

更多细节及可用选项的描述请参见 repo-elephant(8) 。

……好像又是坑爹：

cuihao@cuihao-arch /tmp $ man repo-elephant
没有 repo-elephant 的手册页条目
cuihao@cuihao-arch /tmp $ man 8 repo-elephant
在第 8 节中没有关于 repo-elephant 的手册页条目。

庐山真面目，原来是repo-add啊：

cuihao@cuihao-arch /tmp $ ls -al `which repo-elephant`
lrwxrwxrwx 1 root root 8  1月 13 12:45 /usr/bin/repo-elephant -> repo-add*

打开repo-add，发现这么一些代码：

elephant() {
	case $(( RANDOM % 2 )) in
		0) printf '%s\n' "H4sIAL3qBE4CAyWLwQ3AMAgD/0xh5UPzYiFUMgjq7LUJsk7yIQNAQTAikFUDnqkr" \
		                 "OQFOUm0Wd9pHCi13ONjBpVdqcWx+EdXVX4vXvGv5cgztB9+fJxZ7AAAA"
		;;

		1) printf '%s\n' "H4sIAJVWBU4CA21RMQ7DIBDbeYWrDgQJ7rZ+IA/IB05l69alcx5fc0ASVXUk4jOO" \
		                 "7yAAUWtorygwJ4hlMii0YkJKKRKGvsMsiykl1SalvrMD1gUXyXRkGZPx5OPft81K" \
		                 "tNAiAjyGjYO47h1JjizPkJrCWbK/4C+uLkT7bzpGc7CT9bmOzNSW5WLSO5vexjmH" \
		                 "ZL9JFFZeAa0a2+lKjL2anpYfV+0Zx9LJ+/MC8nRayuDlSNy2rfAPibOzsiWHL0jL" \
		                 "SsjFAQAA"
		;;
	esac | openssl base64 -d | gzip -d
}

# figure out what program we are
cmd=${0##*/}
if [[ $cmd == "repo-elephant" ]]; then
	elephant
	exit 0
fi

Arch开发人员真有聊

总结一些以前疑惑的关于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目录。