Dependency resolution is a function of a package manager to fulfill necessary requirements to allow a type of program ecosystem to operate. The dependencies are created by the packager and ensure that when you pull in a package, that entire ecosystem is satisfied automatically by pulling in more packages.

sbopkg does not perform the dependency resolution of a package manager because it creates the ecosystem (the packages and dependencies) based on requirements you choose. The queue file is just the building order. You're not filling the requirement to simply make a dynamic linker work. You are actually choosing to insert the links into a program binary.

It is manual DR. The packages in the list don't have to be related. You also can make simple mistakes, like putting the packages in the wrong order into the list. In that case packages that are dependent on another will fail to build. sbopkg does no DR and will simply spit out a message that a package failed to build and ask if you want to continue with the list.

A few years ago, I tried - and even succeeded - to build a minimal GNOME2 for Slackware, by hand, lib by lib and app by app. SlackBuilds.org didn't exist at the time, and finding information about the building process was a bit like what we see in these Mission Impossible movies. In the end, I got it figured out. Since that experience, I guess nothing can shock me anymore, and I gladly accept the fact that `whoami` is Slackware's dependency resolver.

This question comes up again and again and I feel compelled to relate an experience of mine.

One of my friends who had never used any Linux distribution before wanted to try one and me being a longtime Slackware user helped him install it on one of his boxes. Now as we all know Slackware and most all other distributions come with a huge amount of software ready to use but all my friend could ask was "How do I install programs on it?" over and over. I tried to explain that there was really little need unless he wanted a specific application that wasn't included. He couldn't seem to wrap his head around the idea that everything he might need as a casual user was already there, he was boggled and thought it couldn't be good enough without installing a different program for everything. Instead of actually trying the software he had just installed, he just assumed it was no good and wanted to add and remove as much "free stuff" as he could.

He was not the only person I knew with this (for lack of a better term) installmania. I believe the idea that something needs to be installed every time you want to read a web page, or edit a text file is just a habit left over from using windows which installs almost no applications by default and everything a user wants to do requires him/her to either go out and purchase it or download and install it.

Sadly my friend never got over his anxiety or need to install applications willy nilly and moved on to Ubuntu which as I've seen with as little as the selection of one program to install can disrupt and literally install thousands of dependencies requiring hours and hours of downloading and processing. Nothing against ubuntu or any linux distribution, power to them all but I'm no fan of automated dependency checking and I do believe the windows mentality is the reason this question is so often brought up.

Please forgive me if this has already been brought up, the thread is long and while I've read most of it I admit I skipped some.

Isn't this whole discussion moot now? sbopkg + queue files is almost as good as a dependency resolver. It's not just as good, but it implements the main feature: if you want package A, then it installs it after installing its dependencies in the correct order. It won't detect incompatible packages, true, but collisions are rare. tetex versus texlive is the only one I can think of. On the other hand, sbopkg won't present you with a maddening decision where removing something as stupid as banshee player takes down half of your desktop, because everything is tied up in a knotty meta-package clusterf**k (looking at you, Ubuntu).

Hmmm, maybe I have the wrong intuition with 'automatic' here. I have assumed than any and all DR would simply be some list of packages to include, in some order, and that, obviously, if that list was flawed, then the DR would be broken. That seems to be what sbopkg does, so I'm wondering what more there could possibly be. Maybe 'automatic DR' is something beyond that, some sort of system that handles DR with no 'queue' and that sorta figures things out all by itself, tho I can't imagine how that could be done.

Like I just posted, that sounds like all that one could wish for, it sounds 'automatic' to me. If it 'installs dependencies' then that's what I'd have called 'dependency resolution'. I guess dpkg and such must do something beyond that, like, as you just said, check up on incompatibilities and such like. I suppose there could be lots of bureaucracy involved, now that I think about it, especially when it comes to removing something.

BTW, I had exactly that happen to me with banshee, it seemed to have tried to make itself unremovable. I also noticed a few strange things with VLC. I guess the bottom line is that whereas I've enjoyed using Synaptic to install and test stuff, and have found that to be quite nice, there have also been not a few disasters even in my own limited experience. Maybe a more manual packaging system is indeed, on balance, the better way.

Dependency resolving package managers are a fine thing *when* they work. I am perfectly happy with manually resolving dependency issues as needed in Slackware. A full installation of Slackware works out of the box with all dependencies met.

Do you know trees? Dependencys are kinda like this:


sbopkg just implements a line of pkgs, if you put them in order they can simulate dependency resolution

But true dependecy resolution implements this tree, it searchs for the bottom dependencys and build them, them it go for the upper level and finnaly build the program you wanna install.

The thing is that there are multiple problems, like doubled dependencys, that if something goes wrong in this process, you will have a lot of work to fix it.

I'd call that a cultural problem. 90% of what we 'know' about our OSs we know without even thinking of it as knowledge, or even being aware of it. Often, when a relative noob like me asks a question, the answers given presume this deep knowledge of Linux culture that the noob just doesn't have. Me, I'm not too contaminated by Windows, OTOH, my internal OS is absolutely integrated with good 'ol DOS--to this day I can't get used to the fact that Linux does not search the current directory first for executables. I wish there was some book: "Linux culture for the DOShead: 100 things that you need to understand about Linux"

The road is long.

There is more to automatic DR than just installing packages from a list. It also involves compatibility checking, alternative systems (software A needs a function that can be delivered by software B or software C, but you can't install both) and then there is the whole part of removing software. If you install software A and software B is installed automatically as dependency then software B will be marked as no longer needed when you remove software A, so that it can be de-installed with the package managers automatic functions. In Slackware you have to track down such things yourself, sbopkg will not do this for you. Best practice if to write down which package you have installed and why.

to get this tree for runtime dependencies I have written sbbdep.
for building dependencies, like if a program uses a static library, there is no auto detection possible (nearly, you would have to monitor and analyse the build and even this would be hard) so the build maintainer must specify them.
also dependencies for/between scripting stuff or software that make calls to libexec can only be specified by the packager/developer

Thanks, [MODERATED]

Now this is a damn good point, and really the best advantage of managing your own dependencies.

But still, what are the consequences? You simply leave Banshee (or package x) installed and don't use it.

If only it was so simple... It integrated itself into the notification area in a compulsory way.