Paludis 试用笔记

亞利艾爾

是。没有什么好争的，觉得顺眼就用。

zhllg

Post by goodmen;1869846

至于楼上说的gentoo和paludis社区之间的矛盾，我看纯粹是不同类型技术人员之间的争吵而已。

...


目前portage包里面包含了可执行的bash代码。我认为这是不妥的。我设想的一个理想设计应该是软件包的ebuild应该仅包含描述性信息——版本号、兼容性、特殊编译选项、依赖性、平台bug、补丁等等。
执行动作应该是由pack manager软件自己完成。这样才能保证整个portage树的稳定。维护portage树的工作量远远大于维护一个pack manager软件（甚至比重新开发一个pack manager软件还困难），所以portage树应该是中立的、稳定的。

事情没有发生到你身上的之前，你永远不会有什么感觉。如果你觉得别人说你是idiot，fcuking bastard，你也只觉得是争吵，那我也无话可说。

ebuild里必须要有逻辑判断，而不能只有变量的定义。所以就算不用bash script，也要有一种语言来实现。

维护portage树的工作量和维护pm的工作量根本就不在一个数量级上，没有可比性
看看gentoo有多少开发者，又有多少portage的维护者就知道了

goodmen

Post by zhllg;1869887
事情没有发生到你身上的之前，你永远不会有什么感觉。如果你觉得别人说你是idiot，fcuking bastard，你也只觉得是争吵，那我也无话可说。

同意，我也反对网络脏话。如果是我，我只会对代码发表看法，只会说某段代码stupid, 不会攻击写代码的人。


"ebuild里必须要有逻辑判断，而不能只有变量的定义。所以就算不用bash script，也要有一种语言来实现。"
能否详细说说，为什么一定需要逻辑判断呢？纯粹描述性的config不能完整地说明package的各种属性吗？能举个反例吗？

"维护portage树的工作量和维护pm的工作量根本就不在一个数量级上，没有可比性"
也许你没有仔细看我前面的帖子，关于这点和你看法是一致的。毕竟软件包的数量是无法限定、永远增长的。

zhllg

只要有USE标记的ebuild，就需要逻辑判断。这个只能这么明显了。这个是最最浅显的需要逻辑判断的情况。

关于维护portage树和pm的工作量，我的意思是说，这个差别太明显了，没有比较的必要，也显不出为什么因此portage树就要中立。
当然portage要中立这点是没错的。
pms是重中之重这也没有问题。
pm是什么写的也无关紧要，只要搞清楚一个的实现，其他的也就触类旁通。

反正paludis在gentoo的前景就目前来说是不明朗的，现在就在它上面投入太多是不明智的。除非仅仅是因为好奇而想研究一下。

亞利艾爾

不光是 USE，有些对内核版本（老版 fuse）要判断，有些要对已有安装包的安装设置（compiz）要判断。如果纯描述显然会更麻烦。

zhllg

Post by zhllg;1870031
只要有USE标记的ebuild，就需要逻辑判断。这个只能这么明显了。这个是最最浅显的需要逻辑判断的情况。

如果觉得这点还不够的话
还可以到/usr/portage/eclass里找些eclass来看看