主要出于两点考虑：提高系统的高度可定制性和系统的稳定性。
如果slackware系统引入依赖性机制，这套机制必然围绕于软件仓库管理员，也就是说你定制软件的权力必须通通移交给管理员。如果你在这套软件依赖性检测机制外自己独立安装了自己的软件A，那你就不能再继续使用这套机制，否则当通过这套机制安装其他软件B的时候，它可能会根据机制来安装它指定的软件A，这样会和已有的软件A存在冲突。如果卸载已有的软件A，则依赖于已有的软件A的软件C有可能与机制指定的软件A不兼容，从而导致软件C运行不稳定。这样的情况重复发生多次时，系统上的不稳定的软件数量越来越多，到最后这个系统就变成不稳定的了。
由于向后兼容一直是计算机软件的通病，高版本的软件并非是完全向后兼容的，而且编译参数不同，软件的特性也不同。
换句话说，同一个软件，由于版本号以及编译方式的不同，其提供的功能不一定是一模一样的。
软件依赖性机制会严重阻碍slackware的风格，所以slackware不引入依赖性机制，它把软件的维护权完完全全地移交给了用户。
slackware尽可能地提供数量丰富的软件，然后测试它们，当它们没有冲突时，最后一次成型地发布出一个slackware系统的版本(软件集合)，然后用户在这个软件集合的基础上构建他们的软件，就如同一个实心圆一样向外扩张，圆内毫无缝隙，这就保障了系统的稳定性和有限度的高度可定制性。

不管linux系统是否引入软件依赖性机制，由于linux系统的软件安装惯例，系统是无法安装多个不同版本的软件，否则就存在文件在位置上的冲突，除非用户自己处理它们，其中一个方案可以是采用静态编译方式安装软件，或者是将软件放置于不同的目录下。
而Windows的软件大多数是独立的，大多数软件都塞到各自相互独立的目录下，所以它很少存在软件冲突。
因此，slackware也可以引入软件依赖性机制，但要另类地改进它们。

这也就是slackware系统更新软件包的数量极少的原因。
底层软件变动太大，上层建筑将会摇摇欲坠。

gentoo表示压力很大，nodejs的npm表示压力很大……
其实，这样的机制唯一好处就是 系统的发行者可以尽可能少地消耗精力，同时可以尽可能多地控制用户的越轨行为。
建议碎片化的android借用这套机制，哈哈