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