[授权转]专业 rpm 包制作神器 multipkg 介绍
2016-12-24 08:43:30
swy
  • 访问次数: 9
  • 注册日期: 2016-12-24
  • 最后登录: 2017-05-15
  • 当前积分: 72

专业 rpm 包制作神器 multipkg 介绍

2016-12-22 cmesoft@126.com 运维刚架构

前言

rpm 包是linux 上比较常见的软件包组织格式;其安装,升级,卸载过程都比较简易,容易上手。但是,由于rpm的灵魂-spec 文件,其格式,语法不太容易理解,或者有些复杂,导致不少 SA, Pe 或者 开发人员,对于“晦涩”的 SPEC 文件编写却敬而远之,结果不少人就放弃了通过 rpm 去管理软件包。转而投靠 scp/rsync 文件复制, tgz压缩包,git,或者一股脑打包进docker 镜像的方式来管理软件。不管长江后浪如何来势汹汹,经典的 rpm 格式软件包依然是如今系统管理的主流软件管理方式,今天仍然值得技术人员去研习,掌握。

multipkg 的出现


  虽然鄙人曾编撰过一本《Linux 软件管理平台设计与实现》的技术书籍,其中以庖丁解牛的方式,大谈特谈了 rpm 是怎么组成的,从协议组成,字段,源码等等,把 rpm 大卸八块,然后又把spec文件,yum的原理等XX了一遍又一遍,觉得 rpm 和 yum 在我面前,基本已经体无完肤,摇摇欲坠,一览无余。 但是,时至今日,当有人来找我问我:我想搞个RPM,你帮我看下spec 怎么写?我依然会果断的回复:“我不会,自己搞去”。
     确实是的,你不可能天天都记得 spec 怎么写,除非你是SCM同学,于是乎,我们开始寻找一种不需要spec 文件的 rpm 制作方式(可能吗?),或者有无能避开spec编写的rpm制作工具? 答案不用猜,肯定是有的,那就是 multipkg(雅虎系有很多好用而朴实的工具):

https://github.com/ytoolshed/multipkg


multipkg 的安装

直接参考官方文档(注意,确保你的机器能连接到公网):
以下部署过程,在centos5,6,7 上都得到验证。


git clone https://github.com/ytoolshed/multipkg.git

cd multipkg

yum install perl-YAML-Syck perl-ExtUtils-MakeMaker

PREFIX=./root PKGVERID=0 INSTALLDIR=source scripts/transform
perl -I ./source/lib root/usr/bin/multipkg -t .

sudo yum -y install multipkg-*rpm

rm multipkg*rpm

git-multipkg -b https://github.com/ytoolshed/ multipkg

sudo yum upgrade ./multipkg*rpm



注意:对于6u的系统,subversion-perl-1.6.11 这个依赖包不好找,需要关注下。
我们都知道,rpm 包从生成过程来比较,分为两类:一类是需要源码编译生成二进制文件的格式,另外一种是不需要源码编译(直接压缩源码)形成的软件包;前者包括 c, java等语言开发的程序,而后者则是一些直接解释,不需要编译成中间代码的语言编写的程序,比如shell,python或者ruby等语言写的程序。因此,本文,在讲述multipkg的用法时,会介绍到这两种不同生成过程的 rpm 包的构建方法。

multipkg 的工作原理


 multipkg 并没有按照 rpm 的格式去写一个rpm文件(《linux软件管理平台设计与实现》第一章中讲到的协议),因为那样做确实太复杂了,像其他工具一样,multipkg在制作rpm格式的软件包时,是基于rpmbuild命令来实现的。也就是说,准备好源码,spec文件,然后放到合适的目录中,调用rpmbuild命令,就编译生成了rpm文件。只不过multipkg把rpmbuild+spec文件这种做包方式用的更优雅些,因为你不需要去关注spec文件,也不需要去关注编译rpm文件的目录,而只需要关注你的源码和编译时hook脚本即可。
     multipkg工作的大致原理是:通过 index.yaml 文件来提供SPEC文件中的所有tag,比如name,version,require,config等信息,然后通过scripts/目录下的post.sh,pre.sh,postun.sh,preun.sh这四个脚本,来存储rpmbuild时在安装前后,卸载前后执行的脚本内容。最后,root目录提供了rpm的文件列表的一部分(因为scripts的脚本中可能会动态创建文件)。source 或者源码压缩包提供了源码。这时,构建rpm的因素就足够了。spec 文件由 index.yaml 文件和scripts 构成。对于需要编译类的工程,源码压缩包或者source 目录中的文件提供了源码。

对于不需要编译类的工程,root 中的文件直接提供了rpm的文件列表和安装路径。这样,在编译时,先通过index.yaml和scripts中的文件替换spec文件模板,生成该工程用的spec文件,然后调整源码和spec文件的目录,调用 rpmbuild命令,作用于源码和spec文件,就形成了rpm包。

multipkg 的目录结构

对于需要编译类的工程,一般就是 index.yaml,scripts/*.sh 和source目录(或者源码包 xxx.tar.gz),例如repobuilder这个工程的目录结构如下:

tree repobuilder/
repobuilder/
├── index.yaml
├── scripts
│   ├── build
│   ├── preun.sh
│   └── run
└── source
    ├── cmthread.c
    ├── colordefine.h
    ├── configserver.c
    ├── configserver.h
    ├── daemon.c
    ├── datadef.h
    ├── inihelper.c
    ├── inihelper.h
    ├── loghelper.c
    ├── main.c
    ├── Makefile
    ├── nethelper.c
    ├── nethelper.h
    ├── os_independent.h
    ├── repo.conf
    └── tags

其中index.yaml的内容如下:

---
default:
  name: repobuilder
  requires:
    - createrepo >= 0.4.11
  summary: muti-thread tasks to update repo of yum server
  version: '1.1.0'
  release: '1'
  group: 'xx'
  packager: 'xxxxx'
  license: 'xxxxx'
  #the multipkg do not support config file for rpm-->need update
  keepopt: 
      - %config(noreplace) /etc/repo.conf
      - %defattr(-,root,root) 
      - %attr(0777 nobody nobody) /etc/repo.conf

scripts/build 的内容如下:

#!/bin/sh
make clean || exit 1
make || exit 1
mkdir -p $DESTDIR/etc/service/repobuilder
mkdir -p $DESTDIR/usr/bin/
install repobuilder $DESTDIR/usr/bin/
install repo.conf $DESTDIR/etc/

又比如wget 工程的目录结构如下:

tree wget/
wget/
├── index.yaml
├── root
│   └── etc
│       └── wget.conf
├── scripts
│   ├── build
│   ├── post.sh
│   └── preun.sh
└── wget-1.14.tar.gz

其中build的内容就是spec中build段的内容,如下:

#!/bin/sh
exec 2>&1 >/tmp/build.log
./configure --prefix=/usr/local/wget --with-ssl=openssl
make
make install

对于不需要编译类的工程,就更简单了,只需要在root目录中放置你的文件即可,比如 pkg-release 这个包就是如此:

tree pkg-release
输出如下:

pkg-release
├── index.yaml
└── root
    ├── bin
    │   └── pkgrelease
    └── etc
        └── pkgrelease.conf

运行命令:

multipkg pkg-release 
后,生成文件 
pkgrelease-1.1.0-1.noarch.rpm
通过命令:
rpm -qpl pkgrelease-1.1.0-1.noarch.rpm
查看该rpm文件包含的文件列表为:
/bin/pkgrelease
/etc/pkgrelease.conf
从上面的结构你应该已经看到了, 在源码目录中,root目录就类似于安装机器的 “/” 目录,这样,在root下怎么存放文件,你的rpm将来就怎样安装到目标机器上去。
使用举例

还是举两个例子,一个是源码编译工程,一个是不需要编译的脚本构成的工程。

源码编译工程

repobuilder 工程的目录树如下:

├── index.yaml
├── scripts
│   ├── build
│   ├── preun.sh
│   └── run
└── source
    ├── cmthread.c
    ├── colordefine.h
    ├── configserver.c
    ├── configserver.h
    ├── daemon.c
    ├── datadef.h
    ├── inihelper.c
    ├── inihelper.h
    ├── loghelper.c
    ├── main.c
    ├── Makefile
    ├── nethelper.c
    ├── nethelper.h
    ├── os_independent.h
    ├── repo.conf
    └── tags

其中source 下的文件就不再重点介绍,是一个标准的C工程,着重看下index.yaml和scripts中内容:

index.yaml:

---
default:
  name: repobuilder
  requires:
    - createrepo >= 0.4.11
  summary: muti-thread tasks to update repo of yum server
  version: '1.1.0'
  release: '1'
  group: 'xxxx'
  packager: 'xxxx'
  license: 'xxxx'
  #the multipkg do not support config file for rpm-->need update
  keepopt: 
      - %config(noreplace) /etc/repo.conf
      - %defattr(-,root,root) 
      - %attr(0777 nobody nobody) /etc/repo.conf

能看到基本的信息,name,version,release,requires等,requires可以写多行,标示依赖多个包,需要注意的是keepopt目前在multipkg中还不支持,这几天我会参考以前的代码,尝试把这个功能加进来。然后看下scripts中的文件:

build:

#!/bin/sh
make clean || exit 1
make || exit 1
mkdir -p $DESTDIR/etc/service/repobuilder
mkdir -p $DESTDIR/usr/bin/
install repobuilder $DESTDIR/usr/bin/
install repo.conf $DESTDIR/etc/

很简单,就是编译,安装。和spec文件中内容一样。


preun:

#!/bin/bash
if [ "$1" = "0" ]; then
        rm /service/repobuilder || exit 1
        /usr/local/bin/svc -dx /etc/service/repobuilder /etc/service/repobuilder/log || exit 1
fi

注意 “$1 = 0”这个判断,在书中,已经说过,preun的第一个参数为0标示是卸载,否则是升级。

run:
multipkg中scripts/run这个脚本比较特殊,是服务启动脚本,也就是自启动脚本,所以,只需要把你
的脚本main函数,或者运行主体脚本保存为scripts/run即可,比如repobuilder的例子,或者,你也可以写出如下的scripts/run:

#!/bin/bash
while true
do
    sleep 5
    date
done

都是可以的。当rpm安装后,这个run的安装路径是:/etc/service/repobuilder/run 也就是说,scripts/run脚本,会为每个想要自启动的脚本添加一个服务目录,路径为:

/etc/service/xxx

这个动作,和“服务”这个说法比较一致,既然是“自启动”,那么就认为其为一个“服务(service)”,所以把运行脚本存储在“/etc/service”下,这种设计比较人性化,容易理解。

 脚本/不需编译类工程

这种工程比较简单,只需要理解 root目录的作用就OK了,看下pkgaudit这个工程的目录结构和文件列表,你应该就明白你的root目录应该怎么存储了:
目录结构:

tree pkgaudit/root/
pkgaudit/root/
├── etc
│   └── pkgaudit.conf
└── usr
    └── local
        └── pkgaudit
            ├── data
            │   └── readme.txt
            └── log
                └── readme

文件列表:

rpm -qpl pkgaudit/pkgaudit-1.0.0-3.noarch.rpm 
/etc/pkgaudit.conf
/etc/service/pkgaudit/log/run
/etc/service/pkgaudit/run
/usr/local/pkgaudit/data/readme.txt
/usr/local/pkgaudit/log/readme


两种情况都包括(源码编译+脚本类)

这类情况下,目录结构也比较简单,你可以认为是在源码编译工程下面添加一个root目录即可,不过这时,你的rpm中包含的文件列表由两部分组成:build安装的文件和root中包含的文件。读者可以自己测试这种情况,并且查看最终生成的rpm包含的文件列表信息。


说明:如果没看懂或者还有啥疑问,可以问我 <cmesoft@126.com>,或者买本我的书来学习《Linux 软件管理平台设计与实现》^_^


qrcode?scene=10000004&size=102&__biz=MzI

微信扫一扫
关注该公众号

swy 最后编辑, 2016-12-25 15:26:19
沙发
2016-12-24 08:44:36
swy
  • 访问次数: 9
  • 注册日期: 2016-12-24
  • 最后登录: 2017-05-15
  • 当前积分: 72
目录结构显示效果不好,回头在桌面机器上调整
1/1