Quote:
Originally Posted by chess
Honestly, after reading similar discussions for years regarding dependency resolution and how Slackware does things, I sort of feel like "either you get it, or you don't."
|
That is also how I explain my passion concerning computers as opposed to being passionate about, say, sports. You either get it, or you don't. Same with Slackware. It does what I want it to do, and stays out of the way when I want to get into the guts of the system. Once I do an initial install of Slackware and do the necessary configuring, using the system is as simple as turning it on.
Honestly, I've read a lot about the Slackware way of doing things, and my thoughts on the subject is that "if there's a will, there's a way". If, after installing a package, I run it on the terminal (I always run it via terminal first, that way I am assured that there will be no unpleasant surprises later on when I click on the program name in the menu), it tells me that it can't find some library, the first command I run is:
ldd $(which <program name>) | grep "not found"
Because, in my experience, you either have no dependency problems at all, or they come in groups, sometimes large ones (ffmpeg comes to mind). The list this commmand generates will give you a good base from which to launch a series of Google searches. If you run a search on the package name appended by "slackware", one of two things will show up. Either someone who maintains a repository has the package you are looking for, or it will be on
pkgs.org. Worst case, you will have to download the source code for the package in question and compile it yourself.
In any case, I find that I have learned something new about the system I run, and I can use that down the road. And I find that that is never a bad thing.
Hope this helps.