SP3 已经发布，默认编码从 GB18030 完全转换成 UTF8 码

jiangtao9999

确实，但你给个好办法？比如你的sp3改用windows作为基础？或者你完全重写linux，所有的函数库，基础服务，核心应用程序你全包？

jiangtao9999

我觉得你根本就不知道linux套件的构成，甚至我怀疑你是不是从0开始编译过系统，是否知道里面的依赖到底是什么概念？

haulm

我不知道999想实现的到底是软件包管理器还是组件包管理器，我没有从零开始编译过系统，只进行过一些尝试，太多的编译问题使得从零开始是一件非常困难的事情。 999 兄很喜欢提到win，我也用 Win，但是现在基本上都是我的家人开启的，我上电脑首先要做的就是重启。
linux套件 的构成可以用 LFS 来解释，依赖我已经说明的很清楚了：

不同的用户对依赖的需求不同，对依赖的程度不同，对依赖的理解也不同，但有一点必需意识到： 依赖提供了一个帮助，这个帮助有利于开发者和重构者，但是对于住在里面的用户来说，他们才不关心房子地基用了多少砖块多少钢材多少螺钉、什么构架、各占地多少。你基本上告诉用户房间有多少平米，已经提供了哪些东西就可以了，你难不成往家里放一台钻探机？

haulm

如果 MGC 是一个完整而无可挑剔的作品，我才不关心它是哪些 linux套件。。。
如果 MGC 拥有很多的软件，我才不关心它里面放了哪些开发库。。。

haulm

依赖 === 框架而已， 框架 === 提供帮助而已， 依赖框架 === 依赖帮助而已
用户不需要自己去建设框架，所以他们不需要框架，我们能提供的不过是其它的帮助，比如告诉用户，这面墙砸出去就对面的管道等等，要不要这么做根据用户自己的意愿，而依赖其实绑架了用户。
至今我都没闹明白，很多用户顺着依赖更新了好多他们不需要的东西是为了什么？

haulm

原帖由 jiangtao9999 于 2010-11-24 17:33 发表
我觉得你根本就不知道linux套件的构成，甚至我怀疑你是不是从0开始编译过系统，是否知道里面的依赖到底是什么概念？

以前我对 se 兄交谈时说不管依赖直接编译了的说法很惊奇，不过后来我发现自己编译组件时也开始 nodpes 了，这时候因为我心里完全明白自己在做什么，而依赖挡住了自己正确的需要。
说了这么多，不知道 999 有没有明白我的意思了，依赖到最后还是要打破的，依赖只是一个准绳，提供一个帮助，但不是必需的。

[ 本帖最后由 haulm 于 2010-11-24 20:35 编辑 ]

jiangtao9999

你要知道，编译依赖分两种，强制依赖和非强制依赖。强制依赖是没有这个包你就不能成功编译，非强制依赖是你没有这个包软件依然可以编译出来。
非强制的代价就是功能不全。你看看 mplayer 的编译就知道了，不同的功能需要不同的依赖。
nodeps 是第一遍编译，正统的做法是你完全做出一个系统的包并且安装后，你应该重新进行至少再一次编译并且重装这个软件包（最好是2遍以上）。Gentoo 的第一遍编译也是一般不打开需要的 USE 变量，等编译成功一遍依赖的东西后，还要重新再编译一次打开新装的提供新的功能的依赖包（这应该属于非强制依赖）。循环依赖现在已经很少了，但并不是没有了。
rpm 的分包还有一个功能是提供不同的功能支持。你的发行版不是 Gentoo 不是 LFS 不是 arch ，用户重新编译不是你的发行版设计初衷。所以，一个程序可以提供 mysql 的接口，也有 sqlite 的接口，你就应该同时提供这些接口的不同分包。用户根据自己的需要安装功能时你应该区别提供。

我以前也说过最精简化发行版其实也是这个理念，并不是不让你提供，而是你要针对用户的不同需要要去别提供，微软的 Windows 这么多年也不是只有一个版本。不同的要求需要不同的软件包组合，这个组合的最小化重合，才是你应该作为基础的发行版。你不能强制一个跑服务器的 Linux 装游戏，同时你也不能让一个为了玩游戏的 Linux 去放弃安装 X 。
但是为了上面的选择，你可能会无法确定系统的软件包组成，因为可能到头来，你发现可能你就只能确定有限的几个包。这个时候才是你发挥软件包集成的时候，你需要根据大多数用户的习惯，提供一些可以尽可能覆盖常用功能的软件包组成最基本的发行版集成的软件系列。但因为前面的要求，你就又不能一大堆的全集成进来。

这个时候，你就又要回到依赖的问题上了。一个提供某个功能的软件可能有多种接口选择，但有可能某些更好的功能实现，你竟然 nodeps 编译而导致你的软件包并没有打开这个功能。你能说这是错误的依赖，应该彻底放弃？就说 php 吧，同时支持那么多的数据库接口，你选择哪个？sqlite ？mysql ？oracle ？你能为你的用户作决定么？你不能，因为你的用户也不能绝对确定。还有例子比如 mplayer ，你到底提供不提供 VCD 的播放功能？ffmpeg 作为系统解码器库，那么多解码器是否全都打开？
至于 rpm 的依赖问题，这还要分自动依赖和手动依赖。
rpm 的自动依赖是保证程序可以运行的基础，你不希望你的用户在运行软件时莫名其妙的根本不运行，结果你检查发现其实是提示没有找到某个 so 吧？没有了自动依赖，你的发行版可能会忘了加入 glibc 这个库。
手动依赖，更多的是上面的功能支持选择。这个软件提供附加的功能，对于一个开源的可以利用别人的劳动果实的软件环境，难道也要自己去写？自然是调用别人了，但你怎么确定这个软件的功能依赖？自动依赖是基于 so 调用的。这个时候自然就需要手动依赖了。
其次，手动依赖也有很多其他的用处。比如 KDE 依赖不依赖 xorg-server ？ smplayer 依赖不依赖 mplayer ？他们就是典型的没有 so 调用的依赖。这都需要去手动依赖。
rpm 的自动依赖是帮你解决硬性指标，弹性指标的选择才是一个发行版制作者需要考虑的。
依赖根本就不是准绳，而是你应该考虑的两部分。一部分是整个软件系统是否可以正常运行，另一部分是软件的功能确定。而这两部分恰恰是一个发行版制作者应该去作的事情，而不是仅仅的把一堆软件包放在一起就能解决的。

打破依赖的最好办法其实就是你干脆作 SP3 的时候，就别把 glibc 放进去，这东西根本没用。
你最好去看看你之前的帖子，发行版等等的东西。你看看是不是有很多问题都是因为不管依赖而导致的。
我之前尝试做 mips 的 mgc ，用 nodeps 来编译很多软件包都是没办法编译成功的。我觉得你有必要从 LFS 开始重新完整搭建一个 mgc 了，你可以很明白的知道自动依赖的根源，手动依赖的作用。
或者，你应该装一套 Gentoo 。明白每个 USE 的变化会带来什么。安装软件时，看看 Gentoo 输出的 dep tree 。感受 gentoo 工具中 revdep-rebuild 的意义。Gentoo 的依赖关系整理的是最好的，arch 和 debian 安装 DE 时，似乎都不会提示安装 xorg-server 的。

haulm

我发现我最大的麻烦倒不是什么依赖，今晚好不容易搞定了 sp3 ，等我实机安装测试后才发现 chromium 居然没更新，还是版本6，而我打包的 chromium 8 给鬼吃了。。。
编译 KDE4 时居然安装着两个 mysql 版本。。。
HOHO， 999 总算认真回帖了。 依赖的整理为的就是提供一个帮助体系的，并不是说全面的依赖就是正确的，那会影响稳定性和性能的。分包是一种办法， 比如 Fedora 尽可能把 PHP 打散成动态库来安装，但为此需要编译 PHP 三次。。。，如果你根本不懂得 PHP 分包和编译三次有什么不一样，那么检索一下 phpinfo 会发现参数一团混乱，而且你很快会发现功能也一团混乱。
尽可能地满足编译依赖，然后分包，这个 KDE4 分包是最典型的这种情况，不管作者是否愿意，反正二进制的阉割超越了 rpm 体系，于是就出现了一些功能丢失和无视。我不知道这些是否合理，但KDE4开发者和分包使用者出现了一些较大的分歧。
依赖有时无法用rpm体系来规范的，除了强制依赖和非强制依赖，还有一个最奇特的环境依赖，所以除非你知道自己的系统都会提供哪些环境，否则根本无从谈论依赖的合理性。
夜也深了，SP3 安装完了还要重新编译浏览器，正如很多奇怪的失误一样。
我也不想再讨论依赖什么的，依赖是本来就是人制定出来的框架，能制做框架也能突破框架，这个本来很平淡的常识，根本不必要大废口水来讨论。
可能我文字上尖锐了一些，我的个性就是如此。强制别人一定接受自己观点很难让人接受。其实我是有主意了，但我们想法是不同的。我不会去重造车轮，有人造框架当然需要有人去破除框架。
目前 MGC 为了编译的方便，环境是大于 KDE4 桌面需求的，我相信自己所做的打包结果会小于正式版优于正式版，因为目前 MGC apt 源打包参数是扩散的，内容是多广的，为此你 apt 添加删除某些东西会造成依赖到 qt3、gnome，所以当 kde4 用户只是想安装某个软件时很可能下载半个gnome 组件群或干脃安装了整个 kde3。这就是依赖带来的麻烦，因为你经常无法控制环境对编译带来的影响，而这种影响又影响到下载用户的环境同步，如果你想打破这个无理的依赖，那么只好由用户重新编译，这个根本原因就是框架对依赖无理地疯长，然后达到自己无法控制为止。
MGC 目前的编译服务器环境实际上连同 kde3 kde4 gnome xfce mono ... 都一起参与到编译，那么肯定有很多难以整理的依赖等着你去处理，而且不正确的打包将把整个系统出卖，环境最大化使得生成的组件有更多运行的不确定性、肥大和依赖陷井。
依赖没有针对性，依赖没有打破的概念，最终依赖成为大家的脚绊石。

[ 本帖最后由 haulm 于 2010-11-25 06:29 编辑 ]

jiangtao9999

依赖不是绊脚石，是linux乃至整个unix的特性。unix因为系统是由大企业大组织统一管理的，底层依赖可以控制。linux本来就是松散组织起来的，你不可能不去管依赖问题。你没办法不管依赖去直接打包制作发行版。
我以前就提出过整理分类，捋清依赖，我不是没目的的。把包分类可以让你确定你需要关注的重点。你现在的重点肯定和 sejishikong 不一样。依赖还有一个问题就是你应该确定每个包的编译参数，明确打开每个功能的开启和关闭，而不是让软件自己去根据当前软件环境自己检测自己决定，除非你能明确这个功能的开与关可以自动处理不会影响功能调用。同时通过手动添加依赖来确定功能对应的依赖包。rpm不是全自动的，软件包制作者的工作还是要自己干的。

jiangtao9999

发行版制作者需要做的最大的工作是明确所有不能明确的事情。

haulm

如果没有别的意见或网卡设置没有提交新的更新结果，晚上就上传 SP3 。

stronghill

我编译了驱动，打开开关后，重启后用netmanager能够直接搜索到其他无线网络，应该是可以用了，最近不发netmanager的新版本了，除非有新的需求

haulm

原帖由 stronghill 于 2010-11-28 14:11 发表
我编译了驱动，打开开关后，重启后用netmanager能够直接搜索到其他无线网络，应该是可以用了，最近不发netmanager的新版本了，除非有新的需求

我想确认一下，如果你的驱动打成包不大的话，我也可考虑直接加进系统中。

haulm

原帖由 stronghill 于 2010-11-28 14:11 发表
我编译了驱动，打开开关后，重启后用netmanager能够直接搜索到其他无线网络，应该是可以用了，最近不发netmanager的新版本了，除非有新的需求

我在系统中集成了你的网卡驱动，来不及测试能否使用。

fox_eagle2003

大家别讨论得伤了和气....
感谢haulm为大伙做的贡献
也谢谢涛涛一直关注haulm的研发工作
你们贡献了这版块至少40%以上的人气
话说过来....TT现在还在用ML么？