Yuan Yijun (bbbush) wrote,
Yuan Yijun
bbbush

所以还是 ybuild 好一些

用了一下 mock

http://fedoraproject.org/wiki/Extras/MockTricks


Using tmpfs to avoid disk access

It's not clear that tmpfs is a huge win anymore, now that autocache works and is a standard feature.

When having enough RAM (1.5-2 GB), using a tmpfs can speedup the 'prep' phase significantly. With 1.5GB RAM on a Celeron 2.8 GHz, populating the buildroot will take 2-5s (seconds) on subsequent builds.

You can either mount /var/lib/mock as a tmpfs, or you can mount each of the build directories under /var/lib/mock as separate tmpfs file systems. The latter lets you use the autocache above and keeps the autocache files on disk, rather than in the tmpfs. If you erase and recreate the autocaches often, keeping them in tmpfs makes sense. If you don't recreate them often, then you should use per-build-directory tmpfs mounts instead.


可惜我只有 1 GB 内存。刚装好的 build root 大概有 220M,解压之后是 580M,就提示内存不足了。买内存吧。不然每次解压 root 实在是太慢了。mock 真是一个过于重量级的系统。

是不是应该把 squid cache 调整到 2 GB 呢。

mock *.src.rpm 可以一次编译出所有软件包,不过这样就没办法检验 build requires 了,那才是主要目的。今天回去试下 for i in *.src.rpm; do mock $i; copy build.log .... 大概就是这样子。还有,这样做是没办法控制编译顺序的,那么依赖关系怎么办?ybuild 看来可以处理这个问题,如果判断出系统中缺少依赖软件包,而依赖软件包是在 repo 中的,就先编译依赖软件包,编译完毕就会执行 createrepo,然后回头编译那个。Createrepo 之后,yautobuilder 也就不存在这种编译顺序问题了。

update:
突然想到,FE 之所以采用 Makefile 的方式,应该也是为了解决编译顺序问题。

坦白地说,工作时间,在利用公司网络玩,并且读一些与工作内容无关的文档,真是太TMD了。可是我又不想用 flash 设计界面,象黄林那样搞。我对那个界面没什么看法。
Tags: linux, 工作
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments