再次建议：Magic Linux + pkgsrc
之前我就提过这样的建议，但是不知道是因为开发组的人员对pkgsrc不了解还是不赞同，始终没有比较权威的成员出来发表一下意见或见解。因此今天我再次提出自己的建议：Magic Linux + PKGSRC。
希望有能力、又赞同这样的组合的朋友能够将它完善一下。
我的观点是：
MGC现在的开发人员严重不足，加上美媒公司的成立，原先的主力开发人员都已经没有太多的时间顾及
MGC的后续开发（谁能够不吃饭做开发？先生存，然后才是毫无报酬的GNU/OpenSource！相信大家不会
有异议。），虽然发布了Magic Linux 2.0正式版，但是软件仓库严重空乏，GNOME的爱好者常常忍痛割爱，
舍MGC而顾其它。前不久GNOME-2.14的发布，GNOME爱好者为之兴奋不已，大幅度的速度提升，越来越强大的
功能和更加友好的操作。
不只是GNOME（它太有代表性了），还有许多非KDE环境的应用程序，大家都需要自己去下载和编译，遇上
依赖关系错综复杂的，只能叹息一声，“罢了罢了”，换个已经有了这个包的发行版用着吧。
MGC以良好的中文支持得到大家的喜爱。那么pkgsrc能否保证这样良好的中文支持呢？
个人认为，现在的情况是，软件本身的中文支持已经做得越来越好，即使碰到中文支持不好的软件，也可以
一改以往的维护整个软件包，而成为只维护patch。减少了许多的工作量。
所以我的观点就是，结合MGC优秀的中文支持，加上pkgsrc带来的丰富的软件仓库，大家可以舒服地使用
心爱的MGC了。
什么是pkgsrc？pkgsrc有什么优点/特色？
简单地说，pkgsrc是NetBSD的软件包管理套件，与FreeBSD/OpenBSD中的ports系统类似。
引用CU上该帖作者dennis2的一些观点（http://bbs.chinaunix.net/viewthread.php?tid=378862）：
另外一个显著的不同是 NetBSD 的 pkgsrc。尽管它是从 FreeBSD 的 ports 派生的，
但在其后的演化中加入了许多新特性，比如用 buildlink 替代 DEPENDS，等等。与
FreeBSD 的 ports 比较，有这些不同：
- 软件安装的 prefix 是 /usr/pkg，而不是 /usr/local（当然如果你愿意，还可以把它变为 /usr/local）。
这样做的好处就是，从源码编译安装的软件仍然可以安装到 /usr/local，而不与 NetBSD 的 pkg 混在一起。
当然 FreeBSD 也可以把 prefix 设为不是 /usr/local，但不是所有的 package 都遵循，有的 package 使用
hardcode 的 prefix (/usr/local)。
- pkgsrc 把一个 software package 的不同的模块分解到不同的 pkg 里，这也是我比较喜欢 pkgsrc 的比较
重要的一点。比如说，对于 php4 这个 pkg，在 FreeBSD 下就需要在编译时选择编译哪些模块，如果安装以后
想要再增加新的模块（或去掉不用的模块），就需要重新编译。NetBSD 则不然，比如说你想安装 php4-mysql，
在安装 php4 后，再进入 /usr/pkgsrc/databases/php4-mysql，然后 make && make install 就可以了，其他
的 php4 模块也是如此。其他的例子还有 subversion，在FreeBSD 下你或者安装 subversion，或者安装
subversion-python。在 pkgsrc 下，你可以安装 subversion-base，然后安装 py-subversion，还可以安装
ap2-subversion (apache2 的 webdav support)，等等。在这一点上，我觉得 pkgsrc 有点象 Debian，把一个
软件包拆成不同的功能块，分别放在不同的 pkg 里面。
- pkgsrc 不仅可以在 NetBSD 上使用，也可以在各种不同的 Linux distribution, FreeBSD, OpenBSD,
Solaris, IRIX, AIX, Darwin (Mac OS X)。我个人就在 Linux 和 Solaris 上用过。
- pkgsrc 里的 pkg 虽然不如 FreeBSD 里面的多（因为要兼顾 NetBSD 支持的各种平台），但许多 missing 的
pkg 可以在 pkgsrc-wip (http://pkgsrc-wip.sourceforge.net/) 里面找到。wip 是 work in progress 的
意思，一个 pkg 在加入 pkgsrc 之前，要经过 wip。wip 里面的 pkg 大多数都能很好地支持 i386，所以在
i386 上可以作为 pkgsrc 的补充。比如 jdk14 （这个是 NetBSD native 的），pflkm 现在还都是在 wip 里面。
pkgsrc的官方文档：
http://www.pkgsrc.org
http://www.netbsd.org/Documentation/pkgsrc/
已有的LINUX+pkgsrc的发行版：VoltaLinux
VoltaLinux简介：
Voltalinux 是基于Slackware Linux的GNU/Linux发行，它采用NetBSD的pkgsrc包管理系统。该项目所提供的预先
编译好的发行能让用户体验Slackware Linux的简洁设计，以及5000多份（现在应该不止这个数了）可安装的NetBSD ports。
这是一篇英文文章，详细讲述了如何在slackware上使用pkgsrc：
Slackware Linux with pkgsrc Packages
这是一篇中文的，详细讲述了如何在Debian上使用pkgsrc：
在 Debian 中使用基于源码的软件包管理
（PS：我在szlug（深圳Linux/Unix用户组）的聚会中有幸见到了该文作者，NetBSD的粉丝 ^_^）
介绍如何使用pkgsrc（中文）：
http://home.educities.edu.tw/rxghome/netbsd/guide-gb/chap-pack.html 基于源码的软件包管理系统？对于众多的普通桌面用户有什么优势？他们没有时间编译，他们甚至懒得修改设置，所以这不是个好主意对 magic 的桌面版。事实上我们对所谓的包管理方式没有多大兴趣，只要简单实用、广泛兼容就好，所以 magic 2.0 选择了 smart，尽管 smart GUI 还很简单。 楼主所说的也就是对所有已知的软件都自带了编译设置，这样做和在/usr/src/SPECS下面堆放一堆供编译rpm包的spec文件似乎没有区别。
不过这种模式的确有其好的地方，目前服务器上提供的下载速度太慢，我倒是建议srpm包改成spec下载好了，可以制做一个专门管理和下载和更新apt源上spec文件，以便于rpm包的制做。大家还可以因此利用交流工具共享各自重新编译的包。
这个不能算是用源码包管理系统，而是加强rpm软件包的灵活性。 可能大家有一点误会：
事实上我们对所谓的包管理方式没有多大兴趣
我的本意是扩充MGC的软件仓库，而不是对所谓的包管理方式做更改 -- 虽然实际上它确实是另一种方式。
可能这种方式不适合初学者吧。
既然这样，作为对稍有经验的用户而言，它也未尝不是一种软件包的来源。而且pkgsrc几乎每天都在更新。可以让你轻松用上最新的软件。 哥们，你听说过mach吗？http://mach.sf.net.
源码级别的包管理，好像最牛比的是gentoo的portage哟*^_^* 哥们，你听说过mach吗？http://mach.sf.net.
源码级别的包管理，好像最牛比的是gentoo的portage哟*^_^*你这家伙，GENTOO俺没玩过，不过知道你是GENTOO大玩家 :D pkg说的是不是archlinux用的包？
要是ML能兼容archlinux的包并使用pacman在线更新那还不爽歪歪？？？ 我赞同楼主提到的需要增加ML的软件源的问题，但我觉得问题的关键不在于包管理方式，而是提供包的人手。
我觉得ML有必要制定一个完善的软件包发布方案，这样可以吸收更多的人来贡献 现在的magic linux 2.0 final部分包是用fedora 的gcc 4编译的，而它自己带的gcc是3.4.4
所以有时候会出现一些很奇怪的bug
下一个版本我正在做，情况会有很大改观。 部分包是 gcc4 编译的？应该不会吧？能否试举几例？ magic最好定在一个版本上开发，这样fc的yum可以兼容，免了很多重新打包的麻烦,magic的原很少，但fc的原很多很全。世界就是因为不统一，所以各厂家一遍又一遍的编译着自己的包，ms就是有一个统一的因素，各厂商才能安心的放在开发上，不必把过多的精力放在打包上，linux的发行必须要提高兼容性，不然就像内部打仗一样混乱，怎么和ms竞争desktop!现在不再与用什么技术，而在于统一。这就像开发上组件复用一样，到那个系统上都能用。 magic最好定在一个版本上开发，这样fc的yum可以兼容，免了很多重新打包的麻烦,magic的原很少，但fc的原很多很全。世界就是因为不统一，所以各厂家一遍又一遍的编译着自己的包，ms就是有一个统一的因素，各厂商才能安心的放在开发上，不必把过多的精力放在打包上，linux的发行必须要提高兼容性，不然就像内部打仗一样混乱，怎么和ms竞争desktop!现在不再与用什么技术，而在于统一。这就像开发上组件复用一样，到那个系统上都能用。
不是想统一就能统一的，就一点Magic 就不可能跟 FC 同步了，那就是开发周期，ML2.0 要一年，而 FC 有足够的人手，半年就更新了，你说怎么统一啊
这也是为什么 Gnome for ml 要做多个仓库了 LZ跟zhz讨论一下看看是否你们联合搞一个实质上的进展。。。 LZ跟zhz讨论一下看看是否你们联合搞一个实质上的进展。。。
zhz是谁？
我自己已经在MGC 2.0 Final上尝试过pkgsrc的CVS版，能够很顺利地安装上许多软件包。正是因为能够成功安装，所以我才提这样的建议的。
如果有尽可能多的人愿意参与，我愿意发起这个尝试。 部分包是 gcc4 编译的？应该不会吧？能否试举几例？
kernel好像不是用magic 中的3.4.4编译的
我重新做ndiswrapper的rpm的时候发现的，出来的module提示version mismatch