求教一下se兄，关于 MI 的环境和安装的问题

haulm

MI 最近给我的体验是十分差的，我至少尝试了十多次的安装和 ISO 的制做，不是 initrd 制做失败就是 level XX，输入XX后就死机。总之 MI 无法正确生成RPM包的安装顺序，执行正确的脚本。
因为失败的多了，反而让我另择思路去考虑什么才是合理的安装方式。首先，是否有必要加载微系统后进行rpm安装？解压一个系统比安装一堆rpm包要快的多，更重要的是不存在rpm包脚本对系统生成的影响。MI 根本无法理解 rpm 包脚本对系统的影响，所以在打包重要的rpm包时千万不要用脚本去修改配置，因为它在 MI 中很可能因为安装顺序无法正确执行。
sunshine兄接手 MI 的唯护，但我看 MI 已经老死，很多相对MI 要future的东西无法被解决。
我不知道 Live 安装方式，是否是 tar 解压缩的方式，即便 Lived 是 rpm 安装模式也肯定比 MI 要安全的多，因为 MI 老去了，很多旧的观念必需要改变了。相比下盗版 win 各种 ghost 安装方式五花八门，难道 Linux 没有一个好用的工具? 早前我见过叫核弹的Linux系统，它的安装就是纯粹的复制安装。
还有一个思路就是，利用 MI 生成最简单的系统，那么它的 rpm 包的安装顺序就非常简单，然后chroot到新的本机系统后再安装其它的rpm包，完成安装工作，一旦发生错误还可以本机上得到分析和解决，而不是在抓瞎。我们知道Win的安装都需要重启几次，为的就是安全、驱动和检测，它并不是和现在的 MI 一样一次chroot 然后执行安装，安装不成功就等于废弃。。。

[ 本帖最后由 haulm 于 2010-7-23 10:03 编辑 ]

haulm

我觉得和MGC的包肯定有关，在MGC2.1根本没出现过MI安装失败，MGC2.5后这个问题就出现了，而且安装越来越慢。

sejishikong

livecd的安装方式，不需要rpm，只是解压压缩包（以lzma压缩的）。只是livecd的容量可能不如安装盘的大。

haulm

考虑一下：安装一个微系统，然后解压缩系统文件，解压缩db数据。
那样 MI 就变得更容易唯护和扩展了。

zy_sunshine

所有MI安装的包，在新系统中要能用rpm删除。rpm2cpio 方式解压缩不能生成rpm数据库。
精简rpm的post脚本是个可行的方案。
现在的rpm安装方式是使用的python rpm模块，这个是为ANACONDA准备的安装方式，post脚本是在安装rpm过程中自动执行的，rpm数据库也是自动生成的。

haulm

原帖由 zy_sunshine 于 2010-7-26 17:33 发表
所有MI安装的包，在新系统中要能用rpm删除。rpm2cpio 方式解压缩不能生成rpm数据库。
精简rpm的post脚本是个可行的方案。
现在的rpm安装方式是使用的python rpm模块，这个是为ANACONDA准备的安装方式，post脚本是在安装rpm ...

windows从来就没提供过删除某系统部件的工具，有时我觉得升级是个好方式么？

jiangtao9999

原帖由 haulm 于 2010-7-27 11:03 AM 发表

windows从来就没提供过删除某系统部件的工具，有时我觉得升级是个好方式么？

这不代表微软不知道该替换什么系统文件。

jiangtao9999

原帖由 zy_sunshine 于 2010-7-26 05:33 PM 发表
所有MI安装的包，在新系统中要能用rpm删除。rpm2cpio 方式解压缩不能生成rpm数据库。
精简rpm的post脚本是个可行的方案。
现在的rpm安装方式是使用的python rpm模块，这个是为ANACONDA准备的安装方式，post脚本是在安装rpm ...

事先准备一个数据库不就行了

zy_sunshine

准备一个数据库是可以的，整个就是ghost安装了。
不过我总觉得ghost不舒服。
ghost可以是一个发布方式。

其实我喜欢archlinux的安装方式，有核心包和扩展包和社区包三种包分类。保证base包安装后系统运行稳定是上层应用软件运行稳定的前提。
这就提到了包分类，是我以后想要加上的功能，实现这个功能时对包依赖问题需要仔细分析。

现在的首要问题是将升级后的MI测试并使其稳定。将MI的所有调试方式搞清楚并简化，然后才是进一步开发。

haulm可以选择一块优化，比如包依赖问题，就可以寻找某种方式能分析出比较正确的包安装顺序。或者分类。或者对包的pre post脚本分析，找到一种可以使用ghost安装的方式。

levindu曾写过一个rpmhelper工具。

我也写过一些分析包依赖问题的python程序，但是感觉还是有些不合适。
最好是使包依赖以图形方式显示出来，便于排查包依赖错误问题。