Why doesn't Slackware resolve dependencies by default?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Why doesn't Slackware resolve dependencies by default?
Hello.
I'm wondering why Slackware doesn't resolve dependencies by default? Yes, i do understand that this might give greater control of the distro as you know exactly what you have etc, but in the end, it's just a waste of time as instead of letting the package manager resolve the dependencies, list and then download them you need to go out hunting for every library and things where as if you're interested in what the dependencies do with an automatic dependency resolve, you can just google it up later. As you will either way end up installing all of the dependencies for that package you want, no exception.
I seriously see no advantage to this. Yes, i know Swaret/slapt-get exists but i'm now talking about the default package managers included in Slackware, and their stance against dependency resolve.
And before you ask, i might be of the "newer" generation of Linux users and i might have been spoiled with the automatic dependency resolve, but as i still can't find any advantage to not having it, i must question Slackwares intention on not "moving forward" and doing this.
Click here to see the post LQ members have rated as the most helpful post in this thread.
Simple. Slack is a thinking man's distro. It's for those of us who enjoy using Linux and not have everything done for us. Less automated bloat is the reason for stability and simplicity. It's a philosophical thing. Moving forward isn't always the best thing. Moving forward so much is the reason many new age distros are not as stable. We believe tried and well tested ways.
I'm wondering why Slackware doesn't resolve dependencies by default?
Because we like it that way.
Slackware is the only major distro now that doesn't do dependency management. If you want dependency management then you can choose from many, many distros. We have a choice of one, so coming in here advocating changing it won't be appreciated..
There are both pros and cons to dependency management and it's been discussed in this forum many times before so I'm not going to revisit it. If you're really interested in the reasoning then try a forum search. The reasoning behind our viewpoint has been well explained in the past.
And before you ask, i might be of the "newer" generation of Linux users and i might have been spoiled with the automatic dependency resolve
Me too, but nonetheless I found my way to Slackware and I like it the way it is. If you don't want to do it yourself you have either the possibility to use a different distro, may be a derivative like Salix, or you can use sbopkg in conjunction with queue-files.
But as said before, just do a forum search and you will see why Slackers like it the way it is.
Automatic dependency resolution might be an advantage but only if you are installing pre-made packages from a central repository (I think that is how TinyCore works). In situations where you are trying to create your own package from a tarball (or some other source) then dependency resolution becomes more problematic - especially if you are competing with an automatic dependency resolver.
It is a sad fact of life that most software manufacturers are not willing to create a Slackware version of their packages. However, this is an advantage for us because it makes it easier to tailor their packages to our requirements.
Apart from taste reasons, which are always debatable, I also see technical reasons behind the decision. I didn't write the tools so I could be wrong. As you know, everything in Slackware is layed out in simplistic ways that help the distribution be as easy to understand as possible. In this sense, the package managers are shell scripts that untar the package contents, run the installation post-script, etc. If you want the package manager to resolve dependencies, it needs to be able to download stuff from the network, have a remote repository infrastructure, it needs to be able to verify the dependency graph, etc. So, IMHO, for a simple distribution, it makes total sense to draw the line earlier, make the package manager simple too and make it work with simple files on the filesystem. This may be a bit inconvenient in some circumstances, but having a nice selection of packages in the base distribution improves the situation, and favors having a stable system in which you're not installing and removing stuff all day. My two cents.
Because we like it Resolving dependencies means i know exactly whats on my machine and where i put it. I can troll the code looking for buggy or suspicious lines making sure everything is too my standard. I see your point though, it does take time, but im willing to take the time to make sure my system is secure If your looking for Slackware with a package manager, Salix and Debian Squeeze do a pretty good job. Ask a Ubuntu or any other 'hold your hand, rubbish distro' how to install something from source. They wouldnt have a clue! Let alone how to read a couple of lines of C. If you want a package manger, then use something else. It seems many thousands of people are comfortable with Slackware
In conclusion, i love Slack the way it is and i hope it never changes.
One more thing, as slackers' systems are most of the time very stable, there is rarely any to install any new software so once in a while dedicate slightly more time to installation is not a big issue. It not that uncommon, that for a year, there is no need to install a new software except security updates which are nicely handled by slackpkg
I seriously see no advantage to this. Yes, i know Swaret/slapt-get exists but i'm now talking about the default package managers included in Slackware, and their stance against dependency resolve.
From my experience I see a distinct disadvantage to dependency resolution package managers. That is, they regularly break and then you are left to manually resolve dependencies by hand. Slackware is designed such that it works out-of-the-box with all dependencies met when one does a full install. The slackpkg utility flawlessly applies security updates. If you wish to install third party software from trusted sources (Robby, Eric, and SBo) the support documentation is second to none.
As the system administrator for my Slackware units I resolve dependencies and enjoy killer uptime which is the envy of the Linux world. Slackers like it this way.
Each to his own.
From my experience I see a distinct disadvantage to dependency resolution package managers. That is, they regularly break and then you are left to manually resolve dependencies by hand.
At the beginning of my linux journey I used Fedora Core, I remember uninstalling one package which, as it later turned out, was part of Gnome DE, you can imagine what happened... Well, it was my fault as I didn't read the message before confirming it
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.