准备升级kernel到2.6.0-t1

cjacker

不知道能不能保证win4lin支持，如果不能支持会在CD2中提供2.4.21的内核。

whlvme

ML1.2就不用了吧，提供Hack后的下载就可以了。等ML2.0再用2.6内核，如何？
按稳定性和兼容性要求，ML1.2作为稳定版，ML2.0作为发展版？

KDE

支持楼上。

cjacker

也有一定的道理，
就保持2.4.21吧。

所有rpm包都已经省级完成，在新的安装程序出来之前会出一个pre-alpha版本。
我正在整理软件包，决定到底要包含那些软件，另外需要调整一些软件包内容。
比如对菜单进行重新构造，对某些软件包进行进一步的精简等等。

KDE

了不起！

jin_liu

建议在CD2上带2.6.0－test的rpm包，因为毕竟还有人想尝试吗

Gavin_tju

据说反应速度要快很多的，我觉得至少应该放到cd2中

footman

[quote:9eecc16fdf="cjacker"]也有一定的道理，
就保持2.4.21吧。

所有rpm包都已经省级完成，在新的安装程序出来之前会出一个pre-alpha版本。
我正在整理软件包，决定到底要包含那些软件，另外需要调整一些软件包内容。
比如对菜单进行重新构造，对某些软件包进行进一步的精简等等。[/quote]

说一下 MagicInstaller 的开发进展吧。这段时间一直在疯狂编码，不过任务实在繁重。目前已经差不多完成的有：xmlgtk 界面引擎，magic.action.server (分为管理进程/动作进程两部分，用于管理长操作)。但 magic.action.server 还没来得及做集成测试，我会争取在今天完成。

为了尽快完成 MagicInstaller，我打算集中精力于安装程序必须完成的任务，具体有：分区与格式化、Bootloader 安装、根用户口令和账号管理、软件包的选择和下载安装。其它硬件配置，打算尽可能放到启动之后让 kudzu 来完成。

不过软件包的选择跟 cjacker 你的工作会很有关系。安装程序肯定需要一个软件包依赖关系和安装顺序的列表，这个表应该从所有备选 RPM 中使用脚本来生成吧？否则工作量会很大。还有软件的分组等等问题，就用 RPM 自身的分组信息？还有默认安装时软件包的列表等等。这方面需要协调一下吧？

等 magic.actions.server 通过集成测试，并适当补充文档以后，我会再发布一次源代码以供测试（争取在 7 月 20 日发布）。然后立即着手分区和格式化部分的开发。我已基本决定使用 GNU Parted 作为低层库。GNU Parted 功能很强，有人用它做图形化界面，据说已经达到 PQMagic 的水平。但我一开始肯定只提供基本功能。使用 GNU Parted 相信未来会有更大的发展空间吧。

任务是繁重的，工作是艰苦的，被扔臭鸡蛋的准备是有的。哈哈。     

樱家冢

[quote:66f8afee6b="Gavin_tju"]据说反应速度要快很多的，我觉得至少应该放到cd2中[/quote]
有那么好吗？

footman

magic.actions.server 已通过集成测试。

cjacker

[quote:50c322a4d9="charlesw"][quote:50c322a4d9="cjacker"]也有一定的道理，
就保持2.4.21吧。

所有rpm包都已经省级完成，在新的安装程序出来之前会出一个pre-alpha版本。
我正在整理软件包，决定到底要包含那些软件，另外需要调整一些软件包内容。
比如对菜单进行重新构造，对某些软件包进行进一步的精简等等。[/quote]

说一下 MagicInstaller 的开发进展吧。这段时间一直在疯狂编码，不过任务实在繁重。目前已经差不多完成的有：xmlgtk 界面引擎，magic.action.server (分为管理进程/动作进程两部分，用于管理长操作)。但 magic.action.server 还没来得及做集成测试，我会争取在今天完成。

为了尽快完成 MagicInstaller，我打算集中精力于安装程序必须完成的任务，具体有：分区与格式化、Bootloader 安装、根用户口令和账号管理、软件包的选择和下载安装。其它硬件配置，打算尽可能放到启动之后让 kudzu 来完成。

不过软件包的选择跟 cjacker 你的工作会很有关系。安装程序肯定需要一个软件包依赖关系和安装顺序的列表，这个表应该从所有备选 RPM 中使用脚本来生成吧？否则工作量会很大。还有软件的分组等等问题，就用 RPM 自身的分组信息？还有默认安装时软件包的列表等等。这方面需要协调一下吧？

等 magic.actions.server 通过集成测试，并适当补充文档以后，我会再发布一次源代码以供测试（争取在 7 月 20 日发布）。然后立即着手分区和格式化部分的开发。我已基本决定使用 GNU Parted 作为低层库。GNU Parted 功能很强，有人用它做图形化界面，据说已经达到 PQMagic 的水平。但我一开始肯定只提供基本功能。使用 GNU Parted 相信未来会有更大的发展空间吧。

任务是繁重的，工作是艰苦的，被扔臭鸡蛋的准备是有的。哈哈。     [/quote]

你读一下rh的genhdlist代码，会自动生成光盘/Magic/base/hdlist两个文件，是berkeley db文件。

至于严格的依赖关系，rh通过comps.xml实现，格式可以见安装CD1中，我也一直沿用了这种方式。

你看一下，通过定义组和定义各个软件包完成，比如：一个软件包：
[code:1]
<package>
     <name>libxml2</name>
     <dependencylist>
     <dependency>glibc</dependency>
     </dependencylist>
</package>
[/code:1]

每次制作发行版都要手工去写这个文件，如果你能搞一套自动的措施就更好了。

[/code]

whlvme

工作成绩出乎意料！

lucida

[quote:b0a003215e="樱家冢"][quote:b0a003215e="Gavin_tju"]据说反应速度要快很多的，我觉得至少应该放到cd2中[/quote]
有那么好吗？[/quote]

2.6在desktop性能上面下了很大功夫
我用下来感觉不错。。。比如重负载的时候xmms/mplayer还能保持连贯

2.6至少不比2.4差，如果你运气足够好，能搞定所有硬件的话 ;-)
软件方面，win4lin不用，vmware已经没问题了

footman

[quote:41f9baf009="cjacker"]
你读一下rh的genhdlist代码，会自动生成光盘/Magic/base/hdlist两个文件，是berkeley db文件。

至于严格的依赖关系，rh通过comps.xml实现，格式可以见安装CD1中，我也一直沿用了这种方式。

你看一下，通过定义组和定义各个软件包完成，比如：一个软件包：
[code:1]
<package>
     <name>libxml2</name>
     <dependencylist>
     <dependency>glibc</dependency>
     </dependencylist>
</package>
[/code:1]

每次制作发行版都要手工去写这个文件，如果你能搞一套自动的措施就更好了。

[/quote]

OK，genhdlist 我一定会读的。关于 comps.xml 的自动生成虽然能做，但却麻烦。我想到的做法是：通过类似 rpm -qp --requires 的方式来找。这样会生成很多对 .so 的依赖。还可能出现一些不是 rpm 包，而是某个 provide 的情况。自动生成要处理所有的这些情况。这方面你是否有什么更好的办法？

今天剩下时间的任务是编写文档，更新网站，为明天的发布做准备。

有关 rpm 的问题我还不会马上考虑，现在首要的是分区和格式化。