[结帖] 想自己做一个基于RHEL的翻版。类似whilte box EL。

cxfcxf

其实直接做成livecd你看如何。。。
redhat centos系列 都只有rescue盘
遵循redhat系列命令的livecd...我想做这个- -

ecserver

建议用debian的方式，源代码比redhat更多，包管理更强。
希望是i686优化的debian.

晨想

Post by 线头
这个构思是不是与我的“构建另类lfs”吻合？

也许吻合。但是我并不是要兼容什么软件而产生这个念头的。而且这样作出的系统，也许和RHEL4完全不兼容。因为方法不同了。

之所以用RHEL4的source，基于以下2点：
1。保证能用，因为已经有一个RHEL4存在了。
2。大家都知道，而且redhat提供的官方ftp，方便大家下载。

晨想

Post by cxfcxf
其实直接做成livecd你看如何。。。
redhat centos系列 都只有rescue盘
遵循redhat系列命令的livecd...我想做这个- -

什么叫遵循 redhat 系列命令？难道有什么命令是redhat独有的？
除了那些 redhat-config-xxxx 之类的配置文件助手等。

livecd，我没想，不过如果系统搞定的话，就做一张livdcd了，那样相信就容易多了。谢谢你的提议。

晨想

Post by ecserver
建议用debian的方式，源代码比redhat更多，包管理更强。
希望是i686优化的debian.

我不清楚debian的方式。你是说apt？  （d00m3d，你来说说吧。）

其实gentoo的那个portage也不错，也很全。而且我更倾向从source编译。再想想先。。。

线头

Post by 终极幻想
也许吻合。但是我并不是要兼容什么软件而产生这个念头的。而且这样作出的系统，也许和RHEL4完全不兼容。因为方法不同了。

之所以用RHEL4的source，基于以下2点：
1。保证能用，因为已经有一个RHEL4存在了。
2。大家都知道，而且redhat提供的官方ftp，方便大家下载。

根据以前的猜测，rhel的sources应该不要lfs的patch了

晨想

可以考虑不用，但是有的地方，也可以参考。patch只是解决问题用的，不是说一定要打还是不打的。：）。

d00m3d

Post by ecserver
建议用debian的方式，源代码比redhat更多，包管理更强。
希望是i686优化的debian.

Debian为了兼容性，其乎所有的二进包都是为i386来做的，只有少部份的包如kernel，及glibc有i686，代价是令到系统严重under-powered！很多人说cpu的优化差别不大，我想这都是因为现代人都已经拥有不错的配置，在他们的机器上体会不到而矣，i686优化的系统明显会比i386的系统跑得快，Arch就是最佳例子了。

今时今日，用i386的人绝对是小数，要找一台真正的i386都机乎要到博物管去了，然而，用pentium来跑Debian、Slackware等的却大有人在，我个认为现代发行版最少都应该以i586出发，当然i686其实已照顾了大多数现代的机器了。

终极幻想的构思是一个"Enterprise from source"的概念，既然是from source codes，那麽就不用忧虑了，编译时指定-march便行。

想了一下，ecserver的构思也不不错，但要变通，意思是不要以Debian的binary based来发行，改用源码。要自己从源码做出i686优化的debian包其实可以透过apt-build来实现的，apt-build跟apt-get很相似，它会跟据指定的源上下载有关的源码，然後按用户在apt-build的配置文件的CFLAGS叁数来进行编译，完成後再制成deb包来安装。

LFS精髓在於自行打造，你是可以完全用源码LFS一个RedHat或者Debian出来的。因此，我觉得可以用RHEL以LFS建立基本系统，再加入Debian管理包的元素，结果就是一个混合RedHat-Debian-LFS的体系，既不re-invent the wheel，challenge也大，又能实现使用源码来达到Enterprise from source，更可以满足终极幻想想学会不懂的东西(指Debian-specific的)，而且也发扬LFS的创造精神，一举数得，这是个win-win-win proposition，不妨考虑考虑。

但是不论是哪一种方式，可能都要写个却本命令系统去打有用的patch。当然路途肯定是畸驱难行的，否则早有人做了。

晨想

看了你们的发言，受到很大的启发。谢谢了。

帅哥，看看楼顶的帖子。里边几个问题要讨论一下。：）。

为了暂时方便，我把上边的内容贴到这里来，不过以后的更新就只更新第一帖了。

以下几点，我觉得需要先决定：
1。Source based/ Binary based?
到底是以编译方式进行，还是直接安装binary，这里涉及好多问题。

问题A：依赖关系。这个应该来说还是相对容易一点，不过建立一个相对完整的软件库的话，也需要不少时间，如果能直接使用gentoo或者FreeBSD之类的别的库存，会简便很多。也不用我们去维护。

问题B：目录放置问题。就是软件configure的时候那些prefix/sysconfdir/libexec 之类的目录，理论是要固定的，不然会引起混乱的。source based方面，脚本都写好的话，那和gentoo就很相似了，难道重新发明一个gentoo么，太麻烦了。binary based，在这方面就容易很多了。

问题C：问题A中的库问题。就是我们来维护的话，量很大的，要有一个系统和规范，让大家遵守这个规范来写。不过这样又和gentoo很相似了。如何避免或者兼容一下？

i686当然是主角，因为我们都有。x86_64就是第二个支持体系。其他的体系慢慢来。到时候x86_64的话，我可以开一个ssh让几个兄弟用。

d00m3d

是binary based的话，等同re-invent the wheel；是source based的话，可能难度很高，是否能纵合一起，用source based然後像slackware哪样不理会包的依赖关系？

(作为介业用的distro好像有点不负责任)