首先，没有哪个发行版会把qt和kde捆上，更大的可能性是你装的那个东西依赖了kde的某个组件，顺带牵上了整个kde+qt。
讨论问题首先要基于一个正确的事实。不然你装啥都可以说成要下载200G依赖。毕竟所有的软件都要libc，按你的逻辑既然都能跟libc捆上，也就是任何包都能关联所有的包了。

其次，打包地狱和依赖地狱本质上是一回事。本质上是足够丰富足够庞大的生态自带的复杂现象。好比perl的哲学认为世界是复杂的，所以就应该There's more than one way to do it一样。这只是一种哲学路线的选择。所以既然打包地狱和依赖地狱没区别，那就选择依赖地狱，至少比打包地狱好一点。这也是我上次在这里发帖的时候说的不喜欢用docker的原因。因为打包地狱这种思路只是用起来爽，并不符合整个系统的设计哲学。

如果类似apple那样，有个强力的管理手段，该淘汰就淘汰，该升级就升级，该不兼容就不兼容，那自然会简化很多。然而这里是个一言不合就fork的开源世界，既然你有了选择的自由，那你就要接受选择的代价，就要具备做出正确选择的能力。

最后，以上是对错的问题，明确对错之后再来讨论好坏的问题。比如某个包它实现的很垃圾，整合程度很低，导致打包的时候依赖关系一大堆啥都要带上，那也只是这个包自己实现的不好的问题，而不是这套机制有什么问题。linux如果老老实实的都走package manager，舒服的很本就没这么多事。

【 在 ayaka 的大作中提到: 】
: 这样至少比依赖地狱强点……你想想，假设你装了gnome桌面，然后你想装的一款软件的UI是QT的，然后你的发行版又把QT和KDE捆在了一起……然后你原本想装一款50M的软件，最后因为依赖下载了700M的包，额外占用1G硬盘……
--
FROM 180.109.232.*

一个技术当然有它的定位和价值，容器在强调快速迭代的运维部署上用的就很舒服。
但如果因此导致泛滥了，以至于所有的东西都容器化打包，那这个就是邪路。

这个问题的关键就在于，“如果链接做的好其实没多大”这个前提不存在。我相信你和这里的很多人都能毫无问题的做到这点，但架不住千千万万的后来人做不到甚至是懒得考虑到这一点。因为容器化的本质是鼓励你不用在打包上花费太多心思。一个哲学上就走糙快猛的路线的方案是不会催生出精细的结果的。现实的结果就是大家都塞个浏览器进去当UI，都是起步就是100M，什么几M的web框架根本就不重要。

【 在 Knightmare 的大作中提到: 】
: 邪路吧，谈不上。
: 其实就是本来应该在编译期解决的问题丢给了部署期，最后就是看哪边能力强呗。
: 至于web框架，如果链接做的好其实没多大，可能也就几M。
: ...................
--
修改:lvsoft FROM 180.109.232.*
FROM 180.109.232.*

那我的观点就是，如果能力还不足以正确的解决这个问题，要么提升能力到能正确解决为止，要么就转行别走这条路，去做自己更擅长的事，然后雇个专业的人来解决这个问题。

能用发行版安装的包都不是事，不能用发行版安装的，有些复杂一点的大型系统，配一个月都是很正常的。你这里这些所谓的“说不清的混乱”，只是毛毛雨罢了。

【 在 ayaka 的大作中提到: 】
: 正确的事实是正确的事实，实际的现象是实际的现象，对你来说可以分清，对其他人就不一定了，我要装一个东西，发行版的打包者决定的依赖造成的问题，有时候不是上游开发能决定的，你可以说我不需要XXX，我只要YYY，然而发行版打包的认为你YYY需要zzz，然后zzz强依赖XXX，到时候就是说不清的混乱，所以现在看见装软件包就发怵，到最后/usr/local里还是有一些自己编译的包，原因很简单，发行版的打包参数不符合自己的需求
--
FROM 180.109.232.*