rpm安装方式...

zy_sunshine

做了几天的rpm分析，每天都在考虑这东西，而且实现了几个调节序列算法，现在记录一下，并且说明一下每种方法的失败和成功的地方。防止以后做rpm依赖再走弯路。

一、已实现的
1、增加 减少依赖关系并提供 basepkg_list 调节包的顺序。
成功 : 实现了可以调节包的顺序
失败 : 包顺序改变后 pre_in post_in 脚本的运行命令可能满足了，但是命令的运行环境可能就不满足了(比如命令存在但缺少某个库...)


2、在依赖关系满足后，又按照 “满足 pre_in post_in 脚依赖” 来调节整个包序列
成功 : 使得每个包运行 pre_in 和 post_in 命令的时候都有会找到命令。
失败 : 同1

因此这几天的忙碌都是失败的...闷

二、待实现的
可以采用如下模式，但不知道是否合理
1、安装 rpm 时不运行pre_in 和 post_in 脚本(安装时生成了rpm数据库)，在安装后再按照依赖序列执行脚本。
     整体还是用rpm安装 类似 rpm -i --noscript

2、在制作 iso 的时候直接生成 rpm 数据库(类似 rpm -i --justdb)，并将数据库打包。安装系统的时候用 rpm2cpio | cpio -di 将所有的rpm释放到目标系统，然后将数据库释放过去，最后按照依赖序列执行脚本。

1和2两种模式安装系统大概相差10分钟左右，相差时间都在生成 rpm 数据库上。释放rpm也就是5-7分钟，执行命令在2-4分钟。
1方法耗费21分钟左右。
2方法耗费10分钟左右。

这两种方法是否会出现不可预料的错误？ 比如 pre_in post_in 在运行的时候...(:O还没发现)

貌似我这几天的 rpm 分析没有白做，起码可以提供多个侧重分析的依赖序列。
最后埋怨一下 rpm ，依赖关系太复杂了, 版本比较竟然有几个不通用... 版本比较的 flag 更是多而复杂，而且未来rpm版本中flag又不知道会不会变。
rpm库倒是给了一个自动生成安装序列的功能，但是谁知道内部是怎么分析的依赖呢? 什么时候有空再测试一下这个功能。

zy_sunshine

不合理的地方 [二、待实现的]
方法2 在释放rpm时不会效验rpm的完整性。

jiangtao9999

rpm完整性可以之前检测。既然安装方式都独立出来了，为什么检测不独立出来？不过这么做是不是太极端了？

zy_sunshine

主要是怕光盘刻录时 iso 中的数据有损坏。
还有可能下载后的 iso 中损坏了rpm包。

当然在制作iso的过程中已经检测了rpm的完整性。

zy_sunshine

我也认为有些极端，但是如果在保证包的整体依赖没有太大问题的情况下，这个方法不失为一个可行的方法。

jiangtao9999

rpm和md5sum哪个快?

haulm

这几天人闷，我也闷，有几次成功制做ISO，然后又在svn几次更新后又不可用了。可见原有的MI存在很多不合理的地方，另外也和现有MGC依赖混乱有关，MGC2.5是在2.0->2.1->2.5这样升级过来的，在包依赖上没有一个增量合理的依赖树，混沌一团。
我比较赞成的是直接解压安装的方式，连RPM数据库都一并移动过去，我所推荐的连rpm包都不用带了，直接可以用于livecd模式的安装。方法3、在制作 iso 的时候直接生成 rpm 数据库(类似 rpm -i --justdb)，并将数据库打包。安装系统的时候用7za将所有的安装内容释放到目标系统，然后将数据库释放过去，放弃rpm方式的安装才用全系统压缩释放才是正确安全的方法，适合于MGC这样松散开发集体的需求。
rpm 体系是用来约束系统组成过程和规范更新的重要体系，但在安装中把它当成安装体系本身就是认知上的一大错误。就连Fedora都放弃传统的rpm安装方式，改用livecd方式了。不推荐重造历史的尘埃。Fedora的传统rpm安装方式提供了定制安装的方便，既然MGC一直没能实现定制安装（其实Fedora也都没安全实现），还不如直接放弃采用NO PACKAGE解压安装的方式。

haulm

还是直接解压的好吧，安装根本和RPM无关，非要扯这个RPM玩上依赖游戏，没意思。

zy_sunshine

OK
确定了，用解压缩方式，rpm完整性就用md5sum效验，数据库是直接生成打包然后释放到目标系统中。
当然，我们还保留原有的rpm安装方式。

不过我担心一件事情，就是...这样在制作 iso 上不考虑依赖问题会使得 MagicLinux 在包上的依赖越来越不注重

我希望是在发行之前用整体安装方式测试一下包依赖是否有严重错误，包括：
1.1、检测有没有缺少依赖的问题。
1.2、检测有没有重复提供依赖(例如某一库文件，据我所知现在的Magic中就有这么几个重复提供某一库文件)支持的问题。循环依赖不可避免。
安装测试利用两种：
2.1、利用自己分析的rpm依赖序列，测试安装。
2.2、利用rpm库自带的rpm安装序列，测试安装。
以上测试就用 rpmdeptool 完成。

ps : 其实包管理的原理并不复杂，为啥内部就这么复杂呢

jiangtao9999

你把所有的检测都放在生成 iso 时吧……
如果可以，我觉得你最好看看 rpm 的数据库操作。为了以后可以进行软件包安装选择做准备……

zy_sunshine

在制作iso时生成md5字典，在安装时通过计算md5然后比较这个字典来判断rpm是否完整。

rpm的数据库操作接口不多啊，只有 Initializing, Rebuilding, and Verifying ，外加 query 和设置需要读取的 rpm 数据库路径。

分包也可以事先打包数据库，也可以在安装时生成数据库。

jiangtao9999

能否绕过rpm直接操作数据库

haulm

原帖由 jiangtao9999 于 2010-8-24 11:38 发表
能否绕过rpm直接操作数据库

直接无视rpm就可以了，没理由让所有组件按照依赖重新走一遍，那是开发者的事，不是最终用户所要承受的东西。

zy_sunshine

明白你那种方法，但是我想要提供两种安装模式，原来的每个包的安装模式也要保留，你说的那种安装也要尽量实现。

#-----------------------------------

To jiangtao
没有必要吧，现在的rpm数据库接口除了不能修改每个包的数据库记录(比如更改依赖关系)，其他的像 初始化数据库，添加包信息，删除包信息，查询包信息那几个接口应该勉强可以完成。

rpm的数据库有很多个，分别保存着各个索引，因此其中的复杂度还是比较高的，如果能直接完美操作数据库，那离重写一个包管理器就不远了...

zy_sunshine

宣告失败...

我彻底服了 rpm
如果之后运行 rpm 数据库中的 pre_in post_in 脚本的话起码下面这个包就不行, 幸亏没有继续，如果实现了，安装完系统后也是一定没声音的。

1. 
   
2. alsa-driver-module-kernel-2.6.30.10-smp-1.0.23-4mgc25
   
3. preinstall :
   
4. echo "   The ALSA driver 1.0.23 will be installed, and the previous version will be backuped if it exists."
   
5. SNDDIR="/lib/modules/2.6.30.10-smp/kernel/sound"
   
6. SNDBAKDIR="/lib/modules/sound.2.6.30.10-smp.alsa_bak"
   
7. if [ -d ${SNDBAKDIR} ];then rm -rf ${SNDBAKDIR};fi && \
   
8. if [ -d ${SNDDIR} ];then mv ${SNDDIR} ${SNDBAKDIR};fi
   
9. rm -f /lib/modules/2.6.30.10-smp/modules.*
   
10. 
    
11. [sunshine@MagicLinux ~]$ rpm -qf /lib/modules/2.6.30.10-smp/kernel/sound/
    
12. alsa-driver-module-kernel-2.6.30.10-smp-1.0.23-4mgc25.i686
    

复制代码