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

ecserver

我的建议：
1。 Binary based
直接安装binary，i586以上架构，我们提供最易安装和快速应用的系统。

问题A：依赖关系。debian是解决得最好的。

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

source/binary base都不是重新发明轮子，因为debian/gentoo的安装都没有达到易用的程度，而且中文的port都太少，不完整。即使是发明轮子，中国的轮子也和其他的不同，路况不一样。magic linux就是不错，可以限于rpm的老旧架构。我建议采用debian的source/binary架构，根据我们需求重新编译，尽量能和debian的原系统100%兼容（i586以上架构），这样可以利用debian最庞大的软件库，首先对其中资源消耗大的，中文要求高的用自己的包替换。arch其实不错，当时另起炉灶，没有3－5年，软件如何齐备。我们既不重新发明一样的轮子，更没有必要一定发明方形的轮子。

问题C：问题A中的库问题。就是我们来维护的话，量很大的，要有一个系统和规范，让大家遵守这个规范来写。
就用debian的规范。

请楼主把几个发行版试试用用，然后好决定。
建议系统:
原创：
LFS/gentoo(source为主)
slackware/redhat/debian（binary为主）
改进：
turbo/mandriva/suse/arch
越靠后的包管理和架构我个人认为越好，对我们启发价值越大。

请兄弟们多加指正，其实我也想了这个问题很长时间，今天说说，见笑大方。

demonlj

不怎么同意楼上的观点，我觉得如果决定使用binary，而且是从REDHAT出发的话。推荐使用包管理器是rpm或者arch的pacman
1.rpm的原因是方便，来源一致：来自redhat
2.pacman处理依赖的能力比debian要强

d00m3d

。。。请继续辩论

d00m3d

刚想起一件事要慎重考虑的，就是关於系统的维护，如果是binary based的话，系统一旦当掉或遭到攻击，网管还是可以用二进包来抢修系统的，比如  http://www.linuxsir.cn/bbs/showthread.php?t=227316

若果是用source based的话，该如何维护呢？

Phaedo

我觉得Debian或Gentoo是适当的候选者。
二者都有好的包管理系统（而且source，binary兼备）和活跃的社区。
如果基于Debian，就做成source-based，因为用Debian的人很少会去自己编译。
如果基于Gentoo，就做成binary-based，因为用Gentoo的人似乎都热衷自己编译以致至今都没有binary的软件库。
这样反其道而行之便不算是reinvent the wheel了。

晨想

看了兄弟这么多发言，感受非常多。说说我的看法：

首先，我先说一下我的帖子的目的。之所以用 RHEL4 的source，不是要用其RPM这个工具，而是为一开始提供方便，免得到处找包下载。我本意并不是要作一个RHEL4的克隆，也许我的标题有点误导。
我设想的系统是完全和rhel4不一样的，或者说根本是不兼容的。也许以后是自成一系的。RPM这个工具我不喜欢，它连自动下载功能似乎都没有。yum似乎可以，不过我不清楚，不说太多。

以下的三点，我也说一下想法：
1。source 还是 binary。
两者共存。source的，可以用pacman来管理下载什么的。binary的直接下载后安装。（对于pacman 后边还有论述。）
但是问题还是那个，prefix/libexecdir/sysconfdir 这些东西的设置。如果还是用arch/debian/gentoo 这些脚本的话，那么其实就是另外一个克隆，一点改变都没有。但是如果不用的话，维护的工作量就会很大了。


2。pacman/apt/paco/emerge 的选择。
我用过了 paco 和 emerge，也看了pacman，正在琢磨apt。

对于apt，我还没用过，看了一下主页说明。感觉有点像Gentoo的emerge，就是又要学习一套新的管理方式。我到现在还不知道如何在gentoo下删除一个软件（我习惯了make uninstall 或者 直接去删除）。这个也是我不用Gentoo的原因。所以我不想这个系统还有这样的包管理。

对于emerge，我还是不太喜欢，原因请看apt 和 pacman说明。

对于paco，功能上需要改进，也许暂时不适合用来做管理器。但是如果需要配合pacman用的话，就很不错，至少有一个工具用作文件记录。

对于pacman这个软件，我个人挺喜欢，因为和我以前的一个设想可以说是吻合的。用bash脚本来作，加上一定的内容来完成任务。而不是像emerge那样的python脚本，我都不知道在干什么。相信多数人都懂 bash，但是不一定懂 Python。但是我不知道如果是source based的话，怎么监控已经安装的文件。（详见论述3。）大眼一看，pacman的一个好处是几乎谁都看得明白，都能按照自己的需求修改。


3。包文件跟踪。file tracking。暂时拿pacman做包管理做例子。
对于binary，很好办，因为没有改变，也没有临时生成文件，直接删除所有安装了的文件就可以了；配置文件等保留。
对于source，就存在如何跟踪安装的文件。谁也不希望反安装后还有什么包遗漏。分开2个情况讨论：

A：支持 make uninstall 的软件，好办。
按照原来的脚本运行一次configure，然后 make uninstall，很干净。

B：需要手动 uninstall 的。
因为没看到 pacman 有什么工具可以解决这个问题，我想是否需要结合paco来解决这个问题。因为这样下来，应该就没什么遗漏的了。能用到手动编译的人，相信Linux能力不会差。实在有什么，自己解决。因为我们不可能把所有问题都解决的。

晨想

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

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

source based的话，不理会依赖关系，你连编译都编译不过去，就不用说是否负责这个问题了：）。

依赖是要的。就是要如何巧妙的处理才是。。。。

youbest

版主是想另做一套发行版吗？
二进制包如果支持的好的话，扩充就变的比较容易了，但这个二进制包是想从其它发行版里直接拿来用？还是说在这个系统里编译好了，能够直接发布给其它用这个系统的人直接使用？前者似乎比较麻烦，需要考虑许多兼容问题，而后者虽然也很烦琐，但似乎更可行一些。

晨想

1. 对于开始一套新的发行版，我虽然开贴的时候没这个想法，但是我现在有这个想法，虽然还是非常迷茫的一个想法。
但是，这个发行版的目标我想定在快速上边，而不像 Redhat/SUSE那样，启动就花半天时间，加载一堆没用的东西，花哨的很。相信很多用户要的不是这个。这个也是我为什么当年用LFS的原因，哪怕再麻烦，一次下来后什么都简单了。

2。在管理上，binary相对于source是方便一点。我打算是自己编译自己的包，用其他系统的，第一没兼容性，第二我们的LFS长处就无法发挥。一开始是很麻烦，尤其要编译所有的软件，但是到了后边就应该会顺手很多。

3。目标系统是i586/i686系列。当然，如果编译脚本等都搞定的话，编译athlon体系等也是很方便的。出来的系统运行也会快一点（根据d00m3d兄的话）。我们甚至可以定制 -o3 之类的极端branch。


因为我不懂C/C++，我想问一下的是，如果 glibc 升级的话，会不会影响到原来已经编译好的程序。gcc应该没问题，只是一个编译器，源码语法问题是另外一个问题。

1。程序用到的函数没改变的情况。
这个情况下，应该是没有问题的，只是单纯的一个升级。
2。ABI改变了。
这个情况下，就会出现函数找不到等错误，导致程序出错。

不知道我说的对不对？

demonlj

lz需要注意一个地方：你这个系统的目标不是一个发行版，用户群不会广，所以不要把目标定的太远。在线升级之类的考虑：还是切实些考虑我们能够投入的时间，选择便捷的途径。
你上面一个帖子的第3点，我个人比较有意见：我比较赞同我们制作这个系统不是将其作为发行版本，而是作为一个制作个人使用、可维护的系统的“方法”。我们可以参考gentoo的方法，将“系统优化”集中到一个配制脚本，让兄弟们在第一次完成系统的时候按照自己的意愿完成优化。但既然要做，我希望要做出于gentoo不同的地方：所有的优化都只要做一次，只要用户不想升级系统、或者重新玩一次，那么即使他重装系统，这些优化也不应该花他太多的时间－－即使用binary。如此一来，我觉得是做了LFS和gentoo之间的一个折中的方案：用户即有很大的自主权限，又不需要太多的重复工作