linux发行

hongbo_ji

我一直有个疑问，为什么magiclinux不是基于gentoo的呢？为什么大家在抱怨rpm的同时，还在magiclinux中使用它呢？我们应该集大家的智慧与力量，做我们自家的，独特的linux。做linux是一个漫长的过程，我们又走出的一步。如果用rpm，那我们就很难走出第一步了。我们应该挑战固有的思想与结构。各位认为如何？

cjacker

[quote:ba301c8498="hongbo_ji"]我一直有个疑问，为什么magiclinux不是基于gentoo的呢？为什么大家在抱怨rpm的同时，还在magiclinux中使用它呢？我们应该集大家的智慧与力量，做我们自家的，独特的linux。做linux是一个漫长的过程，我们又走出的一步。如果用rpm，那我们就很难走出第一步了。我们应该挑战固有的思想与结构。各位认为如何？[/quote]

ML最初构思的时候是提供一个简便的环境，没有考虑过太多网络升级和用户编译的问题，emerge的设计确实非常的好，apt的设计也不错，但是其实有一个问题：
每种设计基本只适用与这一个版本，比如emerg for gentoo, dpkg, apt for deb   ,rpm for rh, suse, mdk，tgz for slackware, tgz for FreeBSD, port for FreeBSD, 还有几个小的版本也有自己的包格式。
虽然现在rpm也有apt了，但是还是需要为某个发行版特意打包才能满足这个版本的apt需求。

就设计来看，依赖关系在apt, emerg,rpm,port是没有区别的，无非是开发者多做少作的问题，比如apt以来关系有开发者定义，装的时候需要就自动给你装上，port的依赖关系也是由port的配置文件定义，编译时需要就自动编译。


说到头，基于Internet的松散开发方式造成了复杂的依赖关系。

不过ebuild确实应该考虑加入系统，因为这个方案应该是最好的网络编译方案了。

hemingway

强烈的RE

hongbo_ji

还有checkinstall方案呢！！！有好多发行版，非让一些rpm包和他们的什么狗屁logo包关联。真是令人生气！！！！如果是一个纯正的kde，就应该可以轻松升级。可就是由那末多不同版本！！！！真想骂大街！！

carlos

这么冲动..........
什么logo包？没听说过

任何发行版所要关注的不仅仅是一个KDE
发行版的目标是要让所有程序都互相配合协同工作

如果你想要纯正的KDE，网上多的是，自己编译一个也行。
GNU/Linux给了你这么多选择，你还骂大街，真是不知好歹

lucida

[quote:bbba3cda2a="hongbo_ji"]还有checkinstall方案呢！！！有好多发行版，非让一些rpm包和他们的什么狗屁logo包关联。真是令人生气！！！！如果是一个纯正的kde，就应该可以轻松升级。可就是由那末多不同版本！！！！真想骂大街！！[/quote]

在rh里面升级自己kde一样很容易啊，用konstruct
不要告诉我你没做过。。

hongbo_ji

是的。linux的好处就是想咋作就咋作！！！所以搞的像今天一样乱。大家的精力都放在不同的地方。所以很少有成功的大项目。单一个kde也要你一样我一样！！！就像空气分子，到处乱闯。无法形成一个和力，完成一个大的项目。楼上的兄台，难道见怪不怪了？kde有他自己的依赖，这在kde.org上可以查到。可一个kde要有好多种rpm包。这不可悲吗？在大家标榜自己能linuxDIY时。心中除了觉得沾沾自喜，难道不为linux担心？我们是不是真的喜爱linux？我个人认为rpm高到头了！！！！正因为linux精神。所以redhat可以肆无忌惮的修改kde。我不是说redhat不好，但你既然要改，就应该将修改加入kde项目（如果修改的果真是好！！）。说到底，就是linux保管理有问题。我们应该像gentoo学习，同时向M$学习！！！！虚心的人才会进步。

KDE

[quote:3e92d901f7="hongbo_ji"]是的。linux的好处就是想咋作就咋作！！！所以搞的像今天一样乱。大家的精力都放在不同的地方。所以很少有成功的大项目。单一个kde也要你一样我一样！！！就像空气分子，到处乱闯。无法形成一个和力，完成一个大的项目。楼上的兄台，难道见怪不怪了？kde有他自己的依赖，这在kde.org上可以查到。可一个kde要有好多种rpm包。这不可悲吗？在大家标榜自己能linuxDIY时。心中除了觉得沾沾自喜，难道不为linux担心？我们是不是真的喜爱linux？我个人认为rpm高到头了！！！！正因为linux精神。所以redhat可以肆无忌惮的修改kde。我不是说redhat不好，但你既然要改，就应该将修改加入kde项目（如果修改的果真是好！！）。说到底，就是linux保管理有问题。我们应该像gentoo学习，同时向M$学习！！！！虚心的人才会进步。[/quote]
hongbo_ji 所说的正是我想说的。linuxer 需要冷静地思考问题，而不是凭冲动办事。

cjacker

我要port portage系统到magic,
大概是debianutils, python-fchecksum,portage等几个包，port的过程不难，但是我关心的是port 过去是否能起到作用，有没有人给我讲一下
安装gentoo的三个stage都做了什么
缺省安装有没有安装portage 树，一定要emerge回来吗？

我想现在的Magic应该可以完整的通过portage搞成gentoo,包括内核什么的，但是
如果我希望使用gentoo 的某些ebuild文件，是不是一定要自己维护port树。

考虑过FreeBSD的port,这个我是精通的，但是移植难度绝对比portage 大，毕竟portage是为linux设计的。

cjacker

[quote:eab2bfc105="hongbo_ji"]还有checkinstall方案呢！！！有好多发行版，非让一些rpm包和他们的什么狗屁logo包关联。真是令人生气！！！！如果是一个纯正的kde，就应该可以轻松升级。可就是由那末多不同版本！！！！真想骂大街！！[/quote]redhat 和mandrake都是这样。
可以原谅，所以后来我要出来单挑，既然linux给了我们一个自由的空间，为什么不出来试一试。

现在我绝对移植portage到Magic,没准有一天还能形成magic portage 树，呵呵。

hongbo_ji

如果Magic也要portage。我愿意加入！！

lucida

portage可能对用户的要求有点高，和目前magic的定位不合。
建议cjacker先从apt rpm开始吧，看看情况

纯的rpm肯定是不适应现在的情况了。

hongbo_ji

可做一个portage GUI，我认为不是不合。要求高是因为用户界面的亲和力不好！；）