刚才试了一下debian，发现太麻烦了

dyte300

装包装了大半天，比如kile依赖texlive，需要多装800多M，到现在还没装上。，感觉还是slackware好。系统完全安装之后，再多装几个包就行了，很简洁，很方便，而且速度好像也更快，比如游戏ioquake和lugaru（兔子打架）感觉更流畅

之前用了半年ubuntu，是很方便，但发现太不稳定了，有时鼠标突然无法点击了

Jockey

嗯，我是刚开始Debian和Slk同时用，后来从Debian转到了Arch
总的说来，Debian并不简约，整个APT架构很复杂，很容易限制用户自主选择的空间
像Slk和Arch，装系统没有的包或者过时的包，并使其与系统包管理整合，也是相当轻松的事情

AutoXBC

不明白你们说的什么，如果装完系统后安装 kile 还要安装 800M 才能使用，那不是正好说明 debian 给了你 800M 的自主选择的权力么？如果你觉得 slackware 装好直接就可以用 kile，那不说明没有选择的余地么。

如果你觉得 slackware 既可以不装那 800M 又可以直接用 kile，那你说说这 800M 到底那个包是多余的？

如果你觉得 apt 架构复杂，那可以指出到底 apt 中的哪个结构是多余的？哪个概念是 arch 中没有的而 arch 又把 debian 中这个概念涉及的问题完整解决了？

Jockey

自主选择？看你想要哪种自主选择，你想要对一个包进行更细粒度的划分(二进制、文档、库、头文件、etc.)？那Debian确实很好；但你想要某个包，这个包又不在官方源里，你又找不到第三方源，只剩下自己做DEB包的选择，是不是很烦？依赖、被依赖、冲突...

APT的容易，作为代价，是概念抽象层太厚了，不够轻便；但薄如蝉翼的抽象层，例如LFS，对于非骨灰级资深用户，日常使用又极为不方便；而就我看来，主流二进制版里，Arch和Slk是最好的，Arch稍微厚一点，Slk稍微轻一点，但都不过分，都恰到好处。

糊涂

Post by Jockey;2143681
......，Arch稍微厚一点，Slk稍微轻一点，......

如此，有机会再学学SLK，毕竟是款很经典的发行版

lastart

kile不依赖texlive，它只是推荐texlive，可以不安装。
对自己能折腾包之间依赖的人，不管用什么包管理软件都不会是问题。
对连依赖和推荐都理不清的人，最好还是不要介入到包依赖的管理比较好。

Jockey

我不喜欢Debian中像perl-doc、python-doc这种包被作为“建议”而非“推荐”，单独安装它们会让我的deborphan -ap4 --ignore-suggests输出变得很长，但我又不想单单就用deborphan -ap4，因为在我看来，“建议”包是我自己显式指定安装的包，而不是某个包的“松散依赖”(如果将“依赖”看成“严格依赖”，“推荐”看成“宽松依赖”的话)。

我能在本地将特定包的“建议”状态改为“推荐”吗？

AutoXBC

我觉得你用 -ap4 就过分了。debian 是倾向于让用户把大多数组件当成黑盒操作的，如果用户非要介入细节，然后抱怨这些细节没办法完全掌握，有点自寻烦恼。

不过既然既有组件上的洁癖，又有 deborphan 参数上的洁癖，那最好自己用虚包把这些问题封装一下，我这里有个简单的 control 模板。
http://www.linuxsir.cn/bbs/thread347237.html

另外我也打过几十个 deb，实在不理解所谓麻烦是怎么回事。 有些工具比如 Checkinstall Ubucompilator 已经让这个过程不能更傻瓜化了。

Jockey

-ap4过分吗？丝毫不过分，-ap2才过分，我只想显示所有optional的叶子包，如何能叫“过分”？FreeBSD里pkg_cutleaves -l，Arch里的pacman -Qte都干这事儿，我这么一路用过来的，早就习以为常且为成熟包管理之必需了。

.deb和APT不“麻烦”，也不“难”，但就是“复杂”，怎么比较复杂？比较的方式是，例如，checkinstall这个工具的实现代码中，生成Debian的.deb包的部分肯定比Slackware的.tgz包的部分，需要更长时间阅读和理解；而不是说，例如，对end-user来说，checkinstall简化了制作包的工作，因而体现了APT的“简单”。

AutoXBC

http://anonscm.debian.org/gitweb ... d0ca521bb1b;hb=HEAD

line 2042~2253 for slackware
211

line 2256~2525 for fedora
269

line 2529~2692 for debian
163

我不是架构师，剥离 end user 的讨论视角是我不能理解的。