rpmdeptool 例子
下载地址http://code.google.com/p/rpmdeptool/
先与MI同步一下脚本(因为这个工具中需要使用 MI 中的一些脚本, 辅助调节嘛)
python rpm_dep_tool.py sync -p <MI path>
然后将 spec/packages 指向待分析的包(与 MI 中配置方法相同)
执行命令生成包依赖关系
python rpm_dep_tool.py step1 step2
当然两步你可以分开执行(step1 step2)
下面我以提升 coreutils 位置的例子来说明使用方法$ python rpm_dep_tool.py query -p coreutils --color
In the 0 CD 88 position
PkgName:
coreutils-7.0-7mgc25.i686.rpm
Length:
1355102
Groups:
System Environment
Base
Dependency:
(0, 80) : util-linux-ng-2.17.2-2mgc25.i686.rpm
(0, 82) : libcap-2.16-1mgc25.i686.rpm
(0, 83) : gmp-4.2.4-2mgc25.i686.rpm
(0, 2) : bash-4.0-1mgc25.i686.rpm
(0, 84) : ncurses-5.7-2.20090207mgc25.i686.rpm
(0, 86) : grep-2.5.3-2mgc25.i686.rpm
(0, 77) : pam-1.1.0-2mgc25.i686.rpm
(0, 87) : libacl-2.2.47-2mgc25.i686.rpm
Include Pkg:
('spec/packages/coreutils-7.0-7mgc25.i686.rpm', 'i686', 1355102L)这里可以看到依赖关系Dependency:,我们需要去掉除bash以外所有的依赖
在spec/specinfo.py中添加remove_deps = {
'coreutils-7.0-7mgc25.i686.rpm':
['util-linux-ng-2.17.2-2mgc25.i686.rpm',
'libcap-2.16-1mgc25.i686.rpm',
'gmp-4.2.4-2mgc25.i686.rpm',
'ncurses-5.7-2.20090207mgc25.i686.rpm',
'grep-2.5.3-2mgc25.i686.rpm',
'pam-1.1.0-2mgc25.i686.rpm',
'libacl-2.2.47-2mgc25.i686.rpm',
]
}
然后在 basepkg_list 中也添加包 coreutils (可以只为包名)
basepkg_list = ['binutils',
'glibc',
#'glibc-common',
#'glibc-static',
#'glibc-utils',
'ncurses-libs',
'ncurses',
'bash',
#'bash-completion',
'coreutils-libs',
'coreutils',
]
运行命令重新生成依赖$ python rpm_dep_tool.py step2
/usr/bin/python scripts/PkgArrange.py -o result/pkgarr.py -l tmp/pkgarr.log重新查看包的序列以及依赖关系$ python rpm_dep_tool.py query -p coreutils --color
In the 0 CD 38 position
PkgName:
coreutils-7.0-7mgc25.i686.rpm
Length:
1355102
Groups:
System Environment
Base
Dependency:
(0, 2) : bash-4.0-1mgc25.i686.rpm
(0, 12) : info-4.13-3mgc25.i686.rpm
(0, 37) : libattr-2.4.43-2mgc25.i686.rpm
Include Pkg:
('spec/packages/coreutils-7.0-7mgc25.i686.rpm', 'i686', 1355102L)我们看到已经从88位置提升到了38位置。
看到这里又出现了两个包依赖
(0, 12) : info-4.13-3mgc25.i686.rpm
(0, 37) : libattr-2.4.43-2mgc25.i686.rpm
,这是因为这两个包依赖在第一步中已经被包含(依赖的子依赖中已经包含),所以在第一步中没有显示这些依赖包。当解除了一些直接依赖后,那些被忽略的依赖包的子依赖就出现喽。
如果不满足现在的序列,继续添加 remove_deps
现在我们查看从第一个包到 coreutils 的序列$ python rpm_dep_tool.py query deps -t coreutils --color
0 :ncurses-base-5.7-2.20090207mgc25.i686.rpm
1 :ncurses-libs-5.7-2.20090207mgc25.i686.rpm
2 :bash-4.0-1mgc25.i686.rpm
3 :tzdata-2009f-2mgc25.noarch.rpm
4 :glibc-common-2.10.1-2mgc25.i686.rpm
5 :setup-2.8.1-1mgc25.noarch.rpm
6 :filesystem-2.4.5-1mgc25.i686.rpm
7 :basesystem-25-1mgc25.noarch.rpm
8 :libgcc-4.4.0-5.i686.rpm
9 :nss-softokn-freebl-3.12.4-1mgc25.i686.rpm
10 :glibc-2.10.1-2mgc25.i686.rpm
11 :zlib-1.2.3-19mgc25.i686.rpm
12 :info-4.13-3mgc25.i686.rpm
13 :binutils-2.19.51.0.2-1mgc25.i686.rpm
14 :kernel-headers-2.6.30.10-5mgc25.i686.rpm
15 :libattr-2.4.43-2mgc25.i686.rpm
16 :coreutils-7.0-7mgc25.i686.rpm调节依赖关系的过程比较复杂
并不一定添加依赖就会使包推后到精确位置
并不一定移除依赖 并指定basepkg_list 就能使包提前精确位置
它只能将包尽量的向前和向后移动,因为过程中会考虑到依赖关系。
如果想要了解更多,推荐直接查看源码。
basepkg_list 是我新添加的一个元素, 目的是要控制最前面几个包的序列.
我推荐在发行制作 iso 时将basepkg_list = ['binutils',
'glibc',
#'glibc-common',
#'glibc-static',
#'glibc-utils',
'ncurses-libs',
'ncurses',
'bash',
#'bash-completion',
'coreutils-libs',
'coreutils',
]这几个包序列按照这个顺序提到最前面, 以满足后面安装rpm时执行 preinstall 脚本.
若要提前这些包的位置, 可以将他们所有依赖去掉 (即在 remove_deps 中添加)
-----------------------------------------
下面是 rpmdeptool 参数的简单介绍.$ python rpm_dep_tool.py --help --color
You can use --color to print the information in color format
***step1***
..............................
任何时候我们都可以加 --help 来查看各个参数的用法, 因此并不需要记住什么. 任何时候都可以加上 --color 参数来查看高亮显示.
我对应着翻译一下上面的help...
$ python rpm_dep_tool.py --help --color
You can use --color to print the information in color format
***step1***
rpm_dep_tool.py step1
生成如下两个文件
tmp/pkginfor.py(这个文件储存着最基本的包信息)
tmp/rpm.log(生成 pkginfor.py 过程中出现的警告和错误记录)
***step2***
rpm_dep_tool.py step2
生成如下两个文件
result/pkgarr.py(调整后的包信息, 主要是破除一些循环依赖, 并根据 spec/specinfo.py 中的配置调整)
tmp/pkgarr.log(生成 pkgarr.py 过程中出现的警告和错误记录)
***query***
rpm_dep_tool.py query -p <PkgName>
打印某一个包的全部信息 -p 后面接 包名称 或 包的文件名
rpm_dep_tool.py query deps [-p PkgName or PkgNum]
-p 后面可以接包名 或者 包的序列号 来指定那个包, rpmdeptool 会从第一个包开始打印直到指定的包.
rpm_dep_tool.py query nodep
打印那些没有任何依赖的包名
***sync***
rpm_dep_tool.py sync -p <MI path>
将<MI path> 指定的 MI 中提取必要文件, 拷贝到 rpmdeptool 中, 更新包处理脚本.
注意, 这是必要的,在 MI 版本更新后, 必须要对这些文件更新, 才能保证 rpmdeptool 的分析过程和当前 MI 相同
***install***
rpm_dep_tool.py install -t <target system path>
根据生成的包序列 pkgarr.py 模拟 MI 安装操作系统时的操作
如果使用 mount 或者 umount 参数, 则不执行安装操作, 只是执行挂载和卸载目标系统目录的虚拟目录(sys proc 等)
[ 本帖最后由 zy_sunshine 于 2011-2-6 09:49 编辑 ] 调节后,如果你感觉很满意当前的包序列,我们可以模拟MI安装一下试试,看看在安装过程中会不会出现不能运行的 pre post 脚本
先找一个目录(磁盘空间要足够哦,大概3G+ , 也可以直接挂接一个空白盘符)
比如是/mnt/tgtsys_root
执行命令
python rpm_dep_tool.py install -t /mnt/tgtsys_root
OK 之后就是漫长的等待... 注意 上面那个命令需要附加root权限
完成后可以查看result下的install.stderr.loginstall.stdout.log两个过程记录文件,看是否出现问题,格式同MI中的 magic.actions.server.log longop.log 在生成依赖关系的过程中
(命令 python rpm_dep_tool.py step1 step2)
会产生两个过程log文件
tmp/pkgarr.logtmp/rpm.log
,通过查看可以了解整体包是否有loop依赖出现,是否有重复提供某一文件出现。格式同MI coreutils 的位置越高,组件安装脚本运行失败的次数就越低,再配合上basepkg_list,那么MI的安装应该趋于合理了,对之前高调说要重写 MI 实在感到汗顔。
页:
[1]