MBS设计初稿 V0.0.3
MBS设计初稿 V0.0.3
作者：lanzinc<[email protected]>
一、简介：
MBS是Magic Build System的缩写。MBS是一套运行在一个相对完整的Linux系统环境中的软件
系统，这套系统在一个XML主控配置文件的控制下自动完成子配置文件和源代码包的下载，工
具链的构建，打包环境的建立，和编译打包工作。最终得到构建一个发行ISO所需的RPM包，
配合MI能构成一个完整的ISO发行。
二、MBS主要的工作流程
1.MBS解析“XML主控文件”根据优先级构建需要下载的文件的队列。
2.MBS启动若干进程，从队列中取出下载任务，并行进行文件的下载，某个进程完成下载
后到下载完成列表中登记，然后从队列中取出新的下载任务，继续工作。
3.当建立工具链需要的文件下载完成后，MBS根据“XML主控文件”在宿主系统（host）
上建立编译包的基础环境，工具链。
4.MBS根据下载任务的完成情况合包的依赖关系构建并动态维护一个可以开始编译打包的
包队列（队列成员包含下一工作需要的资源的索引）。
5.同时MBS启动若干进程，每个进程独立加载Shell，构建合适的环境，然后从4中队列中
取出任务进行编译打包。完成后到完成列表中登记，退出。
6.整个过程中， MBS维持一个独立的进程，接受各个进程的信息，并负责记录到log，和
向各个负责和用户交互的前台进程进行交互。
三、MBS的几个主要的子目标
1.完整的日志系统方便对整个过程进行监视和分析。
2.前后台分离，前台可以是本地的一个X窗口，也可以是一个文本界面的前台，也可以是
一个web服务器。前台停止工作不干扰后台的工作。
3.尽可能使用中文作为交互和日志的工作语言。
4.有一个进度记录系统，当过程意外停止后能重新启动系统从合适的位置继续该过程。
5.MBS的部分组成可以作为MGC3.0用户打包和交流的工具。
四、详细设计：
1.“XML主控文件”的设计
2.子配置文件的设计
子配置文件由spec文件和一个附加配置文件构成
3.几个主要队列和列表的数据结结构
4.MBS要实现的类：
Class-主控XML文档：
其实例化的对象完成对主控XML文的加载和解析，完成一个磁盘文件到一个抽象对
象的转换。
Class-待下载文件队列：
封装了一个待下载文件的队列，和维护该队列的代码
Class-文件下载器：
Class-完成下载文件的表：
封装了一个完成下载文件的表，和维护该完成下载文件的表的代码
Class-工具链建设者
Class-编译打包进程
Class-完成包列表
Class-需打包包列表
Class-待打包包队列
封装了一个具备打包条件等待编译打包的包的队列，和维护该队列的代码
Class-控制与记录进程
Class-前台接口
五、Spec和配置文档库
作为MBS的外部支持，开发组需要维护一个SVN服务器，用来组织和存储“XML主控文件”、
spec文件、子配置文件、补丁等文件。MBS通过和服务器的交互获取这些资源。但该服务器一
般不存储各个软件的源代码，源代码直接从开发者提供的下载位置下载。开发组的开发工作通
过修改或发布新的“XML主控文件”、spec文件、子配置文件、补丁等文件来形成自己的文档
集。从而使开发工作能进行技术积累和延续，能进行沟通和配合。并且Fans们能方便的参与进
来。
“XML主控文件”的设计 草稿：
一个ISO发行版本对于一个MBSMCF文档
文件名：
MBSMCF.<iso版本号>.xml
文档的内容：
“XML主控文件”自身信息：
文档格式版本号：
生成的ISO发行版本信息：
ISO版本号：
ISO 文件名称：
MBS的运行设置：
任务进程记录文件位置：
日志文件位置：
临时文件的位置：
完成下载的文件的位置：
RPM文档存放位置：
最大并行下载进程数：
最大并行编译进程数：
工具链构建控制结：
<<待详细设计>>
拟参考makefile的设计，或直接调用一个makefile
编译打包控制结：
<<待详细设计>>
一个包列表，
每个包的文件下载和补丁编译等操作由两个文档控制
spec文档和一个扩展配置文件（也可能采用一个扩展过的spec文档）。
[ 本帖最后由 Jagen 于 2008-2-19 22:52 编辑 ] 精神上支持哈，水平太菜了，心有余而力不足哦。 我仅仅是把讨论得出来的东西形成文字而已，真的做起来还是要靠大家的参与，开源社区就是集大家的力量，把分散的时间汇聚起来。
我只是因为兴趣，尽力参与而以。
参与进来，大家都是高手
一点一点，坚持，乌龟都能跑得过兔子
mmmm...
想法真的很不错哦！支持！ 有兴趣参加吗？ 我倒是这么觉得，一个MGC整棵树都被规范了，与其做为软件来开发还不如做为一个组织来执行。我们的Linux用户阵营和开发阵营都会越来越庞大，你那种把开发全投给机器的少数人开发模式还不如真实组织好一个新的MGC开发团队。工具以实用为本，开发以用人为本，我倒是希望你把工具链以外的其它知识点组织出来，整个MGC开发文稿有助于壮大我们的开发力量，舍人以食不如舍人予种，这是我的想法，不吐不快。。。 原帖由 lanzinc 于 2008-2-12 18:53 发表 http://www.linuxfans.org/bbs/images/common/back.gif
我仅仅是把讨论得出来的东西形成文字而已，真的做起来还是要靠大家的参与，开源社区就是集大家的力量，把分散的时间汇聚起来。
我只是因为兴趣，尽力参与而以。
参与进来，大家都是高手
一点一点，坚持， ...
强烈支持 没有抛弃人因素的意思，只是把人从一些并不一定需要人去作的事情中解放出来而已。
以人为本的自动化，软件就是将知识经验能力文档化物质化，方便交流与积累，化需为实，化无形为有形。
有类似的尝试，有些很成功，象archlinux的yaourt pacman abs 和 AUR
getoo 也有类似的系统
ALFS也是类似的
也有基于RPM的
比如附件是arch的一个打包控制文件：
----------------------------------------------------------------
# $Id: PKGBUILD,v 1.17 2007/01/30 18:10:51 judd Exp $
# Maintainer: Judd <[email protected]>
pkgname=bzip2
pkgver=1.0.4
pkgrel=1
pkgdesc="A high-quality data compression program"
arch=(i686 x86_64)
url="http://sources.redhat.com/bzip2"
depends=('glibc' 'bash') ------>依赖
source=(http://www.bzip.org/$pkgver/bzip2-$pkgver.tar.gz) ----->源代码包的下载位置
md5sums=('fc310b254f6ba5fbb5da018f04533688') ------------------>校验
build() { ------------------>嵌入编译打包控制脚本
cd $startdir/src/$pkgname-$pkgver
mkdir -p $startdir/pkg/bin $startdir/pkg/usr/share/man/man1
mkdir -p $startdir/pkg/usr/include $startdir/pkg/usr/lib
mkdir -p $startdir/pkg/lib
# add large-file support
sed -e 's/^CFLAGS=\(.*\)$/CFLAGS=\1 \$(BIGFILES)/' -i ./Makefile-libbz2_so
make -f Makefile-libbz2_so || return 1
make bzip2recover libbz2.a || return 1
ln -s libbz2.so.$pkgver libbz2.so
cp bzip2-shared $startdir/pkg/bin/bzip2
cp bzip2recover $startdir/pkg/bin
cp bzip2.1 $startdir/pkg/usr/share/man/man1
mkdir -p $startdir/pkg/usr/include
cp bzlib.h $startdir/pkg/usr/include
cp -a libbz2.so* $startdir/pkg/lib
rm -f $startdir/pkg/usr/lib/libbz2.a
cp libbz2.a $startdir/pkg/usr/lib
cd $startdir/pkg/usr/lib
ln -sf ../../lib/libbz2.so
cd $startdir/pkg/bin
ln -sf bzip2 bunzip2
ln -sf bzip2 bzcat
mv $startdir/pkg/usr/share/man $startdir/pkg/usr
rm -rf $startdir/pkg/usr/share
cd $startdir/pkg/usr/man/man1
ln -sf bzip2.1 bunzip2.1
ln -sf bzip2.1 bzcat.1
ln -sf bzip2.1 bzip2recover.1
}
任何用户借助这种文件都能进行交流
http://aur.archlinux.org/
看看这个网站，这个系统支持了庞大的用户的参与，这种系统并不妨碍用户参与，相反利于人的交流与参与
看看数字：
Statistics
Packages in unsupported 6834
Packages in 1780
Packages added or updated in the past 7 days 343
Registered Users 7135
Trusted Users 26
这还只是AUR中的，不包括ABS部分的 （abstree.txt.tar.gz (30.07 KB) ）
所以结论
这种系统不回变成少数人的玩具！
[ 本帖最后由 lanzinc 于 2008-2-21 20:07 编辑 ] I'm interesting in this area and I suggest to refer to rPath technology such as rBuilder.
页:
[1]