Normal
0
7.8 磅
0
2
false
false
false
MicrosoftInternetExplorer4
RPM
是
Redhat Package Manager
的简称，是由
redhat
公司研制，用在
Linux
系统下的系统包管理工具。
RPM
包目的：是使软件包的安装和卸载过程更容易，简化软件包的建立分发过程，并能用于不同的体系结构，
RPM
系统已成为现在
Linux
系统下包管理工具事实上的标准，并且已经移植到很多商业的
unix
系统之下
。
rpm
打包可以通过编写
spec
文件，使用
rpmbuild
来完成一个
rpm
的打包。
使用
spec
文件的方式打包，对于初学者最难理解的是
install
和
file
节点编写的关系，并且复杂的是，还需要学习
spec
语言中特有的语法和环境变量关系。其次是打包过程，打
rpm
包前需要先把打包的内容，打成
tar.gz
的包，然后拷贝到
rpmbuild
的源码目录内，大部分是
/usr/src/redhat/SOURCES
这个目录，之后再把
spec
文件拷贝到
/usr/src/redhat/SPECS
目录，然后执行打包命令
rpmbuild –bb xxx.spec
，到
/usr/src/redhat/rpms/i386(32
位系统
)
找到新打的包。当然整个过程可以编写
shell
脚本来模拟上述步骤，最终得到打包后的文件。但是
shell
脚本必须和每个项目结合起来，也就是每开一个项目，都要编写与之对应的一个
shell
文件，并且一样要编写
spec
文件，这并没有彻底解决使用
spec
打包的繁琐问题。
学习使用
rpmbuild
打包，学习曲线比较陡峭，并且整个打包过程比较繁琐，尤其当一个产品上线时，如果发现一个
bug
，需要快速修改调用，那么快速打新包是必须，因为线上环境每晚一刻就可能影响数千人的用户体验，而采用
rpmbuild
的方式整个过程非常繁琐，有没有更好更快的方式，作为参考有
checkinstall
。
checkinstall
是一个能从
tar.gz
类的源代码自动生成
RPM
／
Debian
或
Slackware
安装包的程序。通过
checkInstall
，你就能用几乎所有的
tar.gz
类的源代码来生成“干净”的安装或者卸载包。
checkinstall
的使用非常方便，可以从
获取
checkinstall
的
rpm
包，直接部署到我们的机器上，但是我们要打造自己的
checkinstall
，所以我们最好下载源代码来，
。
checkinstall
的原理是追踪
makefile
中的
install
操作（其实是
checkinstall
中的
installwatch
完成此项工作），记录下整个文件相关变化，并最终生成
spec
文件，然后执行
rpmbuild
打包操作，完成打包过程。
但是真实使用
checkinstall
打包时，有个难题。
checkinstall
获取版本号默认的是通过目录名获取的，也就是说我们每次更新一下包都需要更改目录名，当然版本号也可以采用手工输入的方式，面临同样问题的还有包的名称，释放版本号，包依赖，打包者，版权，简介等，这些信息每次打包时，都需要重复填写，对于我们偶尔打个包，这种输入是无所谓的，但是如果频繁打包的话，这样的过程会非常繁琐，并且还容易出错。看我们碰到的问题是，
spec
文件难写，打包繁琐；
checkinstall
只需要些
makefile
文件的
install
操作即可打包，脚本编写简单，但是交互太多，所以，我决定开发一种新的打包方式，简化流程，并结合
spec
和
checkinstall
的优点，这就是
rpm_create
。
rpm_create
打包时，只需要编写
citb
格式文件，当然你会说，
rpm_create
一样需要些打包的配置文件，并没有简化流程。是的，
rpm_create
一样需要编写打包配置文件，流程似乎没有改变，其实不对。看看
citb
文件格式就知道，下面是
rpm_create
带的实例文件，安装
rpm_create
后，
/usr/local/lib/checkinstall/example.citb
既是文件。
###############################################################
# author: ugg
# mail: ugg.xchj@gmail.com
# url: http://code.google.com/p/rpmcreate/
###############################################################
# 需要包的名称
Name: tpm_create_test
# 包的版本信息
Version: 1.0.0
# 释放版本号
Release: 1
# 依赖包
Requires: php , httpd
# 创建者
Packager: ugg
# 摘要信息
Summary: by ugg test
# 版权
copyright: company
# 指定包目标环境平台（ i386 对应 32 系统， x86_64 对应 64 系统， noarch 不区分系统）
Architecture: noarch
PEARPATH=/usr/lib/php/pear/tbs/apps/customhtml
HTDOCSPATH=/var/www/htdocs/apps/customhtml
# 安装脚本开始命令 , 以下部分可以从和 Makefile 中的内容相同即可
install:
mkdir -p $(PEARPATH)
mkdir -p $(HTDOCSPATH)
cp -r ../../src/htdocs/*.php $(PEARPATH)/customhtml
cp -r ../../src/pear/*.php $($HTDOCSPATH)/customhtml
# 以下 shell 命令，要以 TAB 开始每一行
pre:
# 每行命令以 TAB 开始 , 安装包前执行命令
# sudo apachectl restart
preun:
# 每行命令以 TAB 开始 , 卸载包前执行命令
# sudo apachectl restart
postun:
# 每行命令以 TAB 开始 , 卸载包后前执行命令
# sudo apachectl restart
post:
# 每行命令以 TAB 开始 , 删除目录机上的 .svn 目录，安装包后执行
# 注意 find 命令后面的路径必须为目录机上的全路径，不能用其他变量替换全路径
# find /usr/lib/php/pear/tbs/apps/customhtml -type d -name ".svn"|xargs rm -rf
# find /var/www/htdocs/apps/customhtml -type d -name ".svn"|xargs rm -rf
# 打包日志，同 rpm 中的 %changelog
changelog:
# 每行日志以 TAB 开始
* Wed May 20 2009 changjing.xu %{Version}
整个打包配置文件就是如此简单，需要打包时。您只需要更改包的名称，版本号，文件拷贝工作通过
install
节点完成。
Install
里面的操作很简单，就是写
shell
基本即可
比方说，我们和
.citb
文件同级目录下的
test.php
文件，打包安装目标机的
/var/www/htdocs
目录下，那么我就可以这样写
cp ./test.php
/var/www/htdocs/
看见了，就这么简单。具体例子可以参考
例子
好了，写完
citb
文件后，接下来就执行打包命令了
rpm_create
[-citb] xxx.citb
打包完成后，包自动放到与
citb
同级目录下，
-citb
参数可以省略，
rpm_create
一样支持
spec
打包方式，也可以
rpm_create –spec xxx.spec
打包
spec
格式文件。
rpm_create
还有如下特点如下
* 打包命令简单，所需要操作就是指定要打包的 citb 文件。
* 目录随意， citb 可以放置在任意目录内。
* 打包后的文件，放在和 citb 同级目录内。
* 相对于 spec ，更简单的 citb 格式文件编写。只要您会写 shell ，就会写 citb 文件。
* 支持多个 citb 文件同时打包 rpm *.citb 。
* 支持 spec 格式文件打包。
* 项目开源，可以随意修改使用。
* 支持 32-64 系统（已经经过测试）
其实
rpm_create
并没有多高深技术原理在里面，其实我也是在
checkinstall
之上做的封装。简单的说，我修改了原
checkinstall
脚本，为
checkinstall
脚本增加了解析
citb
文件的格式，这个
checkinstall
就可以解析
citb
格式文件中的
Name
，
Version
，
Release
等信息，然后
checkinstall
把
citb
格式文件最终转化为
spec
格式文件，然后调用
rpmbuild
进行打包操作，打包完成后，把
rpm
包拷贝到
citb
格式目录，而
rpm_create
的作用，就是实现检测
citb
的后缀格式是否正确，用来支持同时打多个包操作，我们用一幅图描述上面的关系
rpm_create
来打包原理和
rpmbuild
打包原理是不同的。使用
rpmbuild
打包时，可以直接打源代码包，而
rpm_create
不能打；也就是说
rpm_create
打包时，需要指定源到目的关系，这时候的源是必须存在的文件，而不能是编译后产生的。比如说我们打包一个
C/C++
语言编写的包。
使用
rpmbuild
打包时，我们可以在
spec
指定编译操作，然后把编译后的
.so
文件拷贝到指定目录下，来完成打包。而使用
rpm_create
，您需要自己先手工完成
C/C++
语言的编译工作，产生
.so
文件，然后在
citb
文件中指定这种对应关系。根据我们的经验，这种源代码类型的包，在企业中应用场景比较少的，企业对源代码的管理，基本都是通过
SVN
来管理，真正在生产环境部署时，还是以直接的二进制包为主。对于像
php
这种语言的包来说，根本就无需编译过程的，所以也是不需要编译的，所以这个问题对
rpm
打包并不会有太大影响，但是如果确实需要打源代码包，那么需要您写
spec
文件了。
我们在扩展
rpm_create
时，还需要满足另外一种需求。我们在开发环境下开发完成，并打包后，然后把这个包部署到测试环境上进行测试，测试没有问题后，直接上生产环境，在开发，测试，生产环境上的包应该是一致的。这里就有一个问题，如果我们的产品有连接数据库等设置，那么我们在不同的环境下安装完成包后，需要修改配置文件，更改不同的数据库连接主机，部署包后，直接修改配置文件，这是很危险的操作，有可能造成修改错误，影响产品发布。而在整个打包过程只有开发人员熟悉自己代码结构，了解在开发，测试，生产数据库的
host
，如果开发人员不在的话，
appops
就不会修改配置文件，所以这些都是很危险的，为此我为
citb
新增
3
个节点，
dev,tst,prd
# dev 环境下执行的 shell 命令
dev:
# echo "dev"
# tst 环境下执行的 shell 命令
tst:
# echo "tst"
# prd 环境下执行的 shell 命令
prd:
# echo "prd"
dev-
表示在开发环境下，执行的
shell
命令，同理
tst
是测试环境，
prd
是生产环境。当然，
rpm
包本身是没有方法可以判断一台服务器是开发，还是测试的。所以，我们的办法是创建
/var/tpm/create/tpm
文件，如果在开发服务器创建，就在里面写
dev
，同理在测试服务器上就写
tst
，生产服务器上写
prd
，按照这样的约定，只需要我们在打包的过程，在
citb
的相关节点上写明在不同环境下的操作，那么安装这个包时，我们就无需手工更改配置文件了。这种方式，也可以通过
spec
方式来支持，如果感兴趣可以联系我。
rpm_create
开源链接
http://code.google.com/p/rpmcreate
rpm
包直接下载
http://code.google.com/p/rpmcreate/downloads/list
相关资料链接：
checkinstall
http://asic-linux.com.mx/~izto/checkinstall/files/source/checkinstall-1.6.1.tgz
rpm_create
地址
http://code.google.com/p/rpmcreate
。