Because it's not an exact analogy. Because with software, you don't necessarily need all the constituent parts already in the mix. Because it is absolutely NOT A PROBLEM if an executable exists on your system that hasn't got all its dependencies, provided that you never use that executable. And if you DO want to use the incomplete executable one day, you can install the deps "just in time", if you want, or change your mind, if you don't want.

Once upon a time there was Multics. On Multics, everything was linked truly dynamically -- not when an executable was loaded, but later, when the executable made its first reference to the external object. External object missing? A linkage_error condition put you up a command level (edit: == opened a subshell), and you could fulfil the dependency -- even by compiling something new -- and resume the program as if nothing unusual had ever happened. This pathetic obsession about missing dependencies that are likely never invoked strikes an old Multician like me as bizarre to the point of OCD. So ldd says 'not found' a few times on something you'll never use? Sheesh, get over it.

1 members found this post helpful.

I returned to Slack a couple of months back after using Arch for a year or so. I'm not finding the absence of DR at all problematic - e.g. I wanted Digikam for its 16 bit support so got the tarball and got the 2 packages it needed via sbopkg. OK it's not fully automated but it wasn't remotely difficult - I kind of like compiling my own packages. It's the shortest line from developer to user and that has to be a good thing.

To highlight a difference in approach between Arch and Slack, NVIDIA drivers and kernel were updated on Arch recently, which caused random X freezes with my GPU and kernel panics with my Ralink wireless drivers. Once I'd downgraded, I had to prevent Arch from updating the drivers and kernel, whereas in Slack I can change if and when I want or need to. It's great. The simplicity of Slackware serves a purpose - Slackware is easily the best performing Linux distro I've used.

I used to think of the lack of automated DR as a price worth paying, but, now, wiser perhaps, I see that it's actually a good way to have things - it does ask questions of the user sometimes, but, as they say, if you want to learn Linux, use Slackware. That cuts both ways.

Some observations about all this:

First of all, I've used many of the Linux distributions and the BSDs for many years and have primarily used Slackware and Arch in the last several.

The dependency problem in Slackware is usually not much of an issue, because Patrick includes so much in what he distributes that, except for major exceptions like Gnucash, most packages from, say, slackbuilds.org just build. At a time when disk-space is dirt cheap, this is a very sensible strategy. But you do run into exceptions like Gnucash, and then it's a real pain to get it and its dependencies built the first time, and in the correct order. I say "the first time" because one you've built the Slackware packages, distributing them among multiple computers is easy.

Arch is very nice and seems to have improved over the years. I tried it some years ago and gave up on it when pacman -Syu hosed my system more than once. They don't have official releases, but instead use the "rolling" release approach also used by Gentoo. This means that their approach to QA is exactly the opposite of what Patrick does. He gives us a big chunk of software that has been thoroughly tested as a chunk and then we pretty much wait a year or more for him to do it again (yes, there are updates available, easily accessible with slapt-get, but the basic point stands). Arch makes updates to bits and pieces available more or less continuously and so its impossible to test the whole thing every time a new version of one of thousands of component parts is made available. But lately (I've been running it for four or five months), it has been dead reliable, at least for me.

Of course, automated package management doesn't imply rolling releases. Debian releases at a glacial pace and OpenBSD releases every six months and both offer automated package management. I can't speak about Debian from recent personal experience, but I can say that OpenBSD is rock solid. But if you care about Flash (which they argue you shouldn't), you're out of luck with this system. But if you want bullet-proof reliability with package management and great attention to security and correctness, OpenBSD is an option to consider. Don't expect hand-holding on their mailing lists, though. They get famously nasty when stupid questions are asked, and sometimes even when smart question are asked. And if you want the absolute latest and greatest version of packages, this is either not the system for you, or you have to build those that you care about from source, which is even less automation than Slackware provides.

My recommendation to the OP would be to give Arch a try, if the objective is to take a first step away from Ubuntu/Mint-like bloat. It will be less of a shock to the (human) system than Slackware and may provide sufficient reliability with the convenience of very nice automated package management. I run it with just a window manager -- dwm. I prefer tiling window managers and don't like the gazillion moving parts of today's desktops. I use rox-filer as my filesystem browser and I've modified dwmstatus (available from suckless.org, together with dwm) to give me the info I want about what's going on in the system. I've also applied patches to dwm to provide per-tag state and vertical tiling (I am trying to convince the author, Anslem Garber, that these features are essential and should be part of his releases).

/Don Allen

I have used Debian and Red Hat extensively, and by "used", I mean admin duties. I've built custom packages, rebuilt packages, done the apt pinning, and rpm database tricks, I've ripped out stock packages and replaced with something newer, or different.

I'm a paid systems admin. I'm not great, but I'm not bad either. I know RHEL because it pays to know RHEL.

That said, I personally don't need or want a huge packaging layer in my operating system. And I use Slackware when ever, and where ever I can.

I don't think people who come from a gui/desktop/enduser point of view will "get it". And they always ask the question again. "Why are you rebuilding your own carburetor? Why are you brewing your own beer? Why are you growing your own tomatoes? Why are wiring your own 220v dryer circuit? Why are you manually doing dependency management?"

BECAUSE I CAN.

1 members found this post helpful.

Really.

They always ask me....

Why do you drink?
"to get drunk"

Why do you roll smoke?
"to get stoned"

Why must you resolve the dependencies that you installed?
"to get laid"

2 members found this post helpful.

Why did the chicken cross the road?

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."

4 members found this post helpful.

This is a slackbuild.org package to show you how it works. Please note that it tells you at the bottom which dependencies that you need. The dependency will be at slackbuild.org and you just need to build that package first. There is also a complete rundown on how to build the package on slackbuild. If you will build that package as it is, most all packages will be the same.
________________________________________________________________
SlackBuilds Repository
13.37 > Misc > conkyforecast (2.24)

conkyForecast is a python script created to provide weather forecast
information to be displayed in Conky. It uses the Weather.com XOAP
service to retrieve data for all over the world.

This requires conky.
_________________________________________________________________

I'd rather say that Slackware is the last remaining distro/car with manual gearshifting, while all other distributions/cars have moved on to automatic gears. And I much prefer manual gearshifting (on my old Mercedes) when I drive.

1 members found this post helpful.

same here. I prefer manual gearshifting rather than automatic

1 members found this post helpful.

Due to neither of them being Slackware. You can no doubt see from my sig I have been on LQ since 2003, about the time I started using Slackware. This topic has come up numerous times, and I have always come down on the side that DR ought to be included. However, it's absence won't stop me using it or driving me away.

Did I say I needed to configure it all the time?
It just so happens that I do a fair amount of video editing as a hobby, so nothing that I am being paid for. And I also happen to prefer to use kdenlive. (just chosen as an example, add your own program of choice here)
Tried building it lately? has a long list of dependencies, some of which are included already within Slackware, some which aren't. And some of those dependencies have others of their own. Then every time there are major changes either to the base system, or kdenlive itself, there is a very good chance it stops working leading to a laborious and frustrating rebuild, sometimes for hours. Time better spent rendering video, (working) rather than building the tools needed to do it.

But as I said, it's not going to put me off using Slackware, and I am now used to it and the stability it brings. But that doesn't mean I have to be happy about DR not being included and neither does it mean that I should stop being on the side of it being introduced.

If you want something from slackbuilds.org, and it's got quite a few dependencies available from slackbuilds.org, use sbopkg and queuefiles - easy.

Here is my insight on this. Slackware is my primary system but I also use other systems with dependency checking.

With the recommended Slackware "Full Install" all dependencies are taken care of "automatically".

If I want to add non-Slackware program X, and it depends on programs A, B and C, with optional dependences on programs D and E. To add to this, programs A and B have compile time optional parameters and program C is already installed. Now herein lies the problem with automatic dependency checking. Will I be able to get the mix I want with automatic dependency checking? Perhaps, if there are several optional installs available and one of those happens to match my wishes. In most cases I will not be able to get exactly what I want. The folks that put these together have to create the packages and dependencies to fit a wide audience and not just little old me.

Here is a simple example of a program I used to use, it contained drivers for many type of devices. In my setup I only had two types. When compiling I could optionally exclude everything but the drivers I needed. With other dependency checking systems I had to settle with the works. Even the SlackBuild script on SlackBuilds.org came fully loaded. I modified it to fit my situation. Can't easily do that in a system with auto-magic dependency checking.

Another example is a program I like to use, it has several entries in Synaptic, there is the obvious base program and the a boat load of optional ones and dependencies. Not a real problem in it self I just install everything I want. The problem is there are a couple of what I consider key optional programs that are not available. That means I have to try and roll my own, or ask to have them added. Both of which are a lot easier said that done. In Slackware I can easily take care of this problem. When you start rolling your own in a dependency checking system you can also add more problems that are harder to resolve that they would be in Slackware since you know exactly what you did.

I pick what is dependent or recommended. I do not have to rely on someone else to decide. These depends in other system are not always dependencies.

Perhaps on the first time install. Scripts can automate the whole process if you want them to. Just start the script. Why the "I hope not." That is what Slackware is all about.

No one is trying to make things difficult. This is the Slackware way. You want easy do not install non-Slackware programs or more simply put do not use Slackware. I've already pointed out some of the problems with automatic checking.

Good for arch, it not Slackware. There is nothing bad about automatic dependency checking. It has it's place, just not in Slackware.

Im a comparatively new slackware user, since June 3 of this year, and i have kept up with the current branch. I have not run into any dependency issues, except with one peice of software and that was wxcam. I found everything i needed to install it, including the wxcam package itself, at slackbuilds.org.

Despite its reputation as something for ubergeeks, i have found slackware to be possibly the most trouble free distro i can remember using.
If you want to give slackware a try i think you will be pleasantly surprised at how easy it is to upgrade and maintain.

If you are looking for something with a graphical package management tool, try vector. Their package management tool, gslapt, does track dependencies and in my experience does an excellent job of it. Vector also includes a graphical system management tool and the support forum allows you almost immediate access to the developers and packagers.

Why not? How else do you propose to get the dependencies needed? How else do all other operating systems do it? That's right, they all go off and find the dependencies and then install them. If you run setup.exe from a CD on Windows and the setup routine discovers you don't have .NET installed the setup routine will either install it from the CD or go out on the net to collect it and then install it. Do you know how long that can take? What does Debian do when it finds a dependency is unmet? That's right: it downloads and installs the dependencies one by one until your requirements are satisfied.

The only thing about the way these operating systems do it is that they *assume control* over the process from start to finish. Slackware gives you that control. But one thing I have found is that Slackware is not for the lazy. It's far from difficult - in fact it's dead simple. But it's not for the lazy. If you want to "look under the hood and take charge of your system" then Slackware is just the OS for you. If you're lazy you might as well stick with Mint.

Slackware is easy and gives you as much control as you can reasonably expect. But as I say, it's not for the lazy. The other thing about Slackware is that there's no point judging it in advance. Unless you're prepared to knuckle down and work with the system for a few months you're not in a position to adjudicate.

Once I discovered how easy it is in Slackware to customise a Postfix Slackbuild there was no way I was going back to the dependency hell of Debian. But as I say, it's not for the lazy.

1 members found this post helpful.