Greetings slackers,

K, so I've been running Mint because it's the first Linux that I managed to get working, but it's past time to try a distro that lets me look under the hood and take charge of my system. I've narrowed it down to Arch, or Slackware (or a derivative like Salix or Vector). There's things to be admired in both universes, but one thing has me stopped dead in my tracks and that's the whole package management 'depencency resolution' thing. Virtually every distro but Slackware gives you DR; it sounds like a no-brainer, an obviously good thing like the electric light. Yet, slackers not only get by without it, they seem to be positively glad they don't have it. I read about 'control' and avoiding bloat and such.

I am confused. If some app 'depends on' xyz then surely it *must* have xyz, no? If it must have it, then why/when would I *not* want that dependency taken care of automatically? Here with Mint, Synaptic, often tells me that something is 'recommended'. OK, that makes it clear to me that 'depends' means just that, and that 'recommends' is something I might do without. How would things be better in Slackware?

In Slackware, what happens when there is a dependency? Do we spend the next few hours downloading and installing these one by one? I hope not. There are folks out there who enjoy making things difficult, but I'm not one of them. IMHO things should be as easy as they can be *without* sacrificing complete control. So, in Slack, what happens? If I have more control, what do I 'do' with that control that I would not be able to do with automatic DR as in Synaptic? For their part, Arch has a similar minimalist, 'direct control' attitude, but they have DR, which makes me wonder if DR is really such a bad thing.

Thanks for any insights.

This old Chesnut again. I am a fairly long time user of Slackware and have the same reservations about you when it comes to DR. I have even been known to start threads about it.
But eventually, you sort of get used to it being in your own control. That's not to say it's any better like that, but unless/until Pat decides otherwise then we're stuck with it.
FWIW, I would relish automatic DR, but don't expect to see it any time soon.

3 members found this post helpful.

Dependencies aren't always needed by another package, they can be optional. Just take a look at ffmpeg, mplayer, and many GNOME apps.

There are problems with automatic dependency resolution. For one, it's hard to build your own packages that don't install using the same dependency manager. For example, you would have to make RPMs or DEBs of any package you wanted to install on Fedora or Ubuntu, respectively. If you didn't make a package or couldn't then things would not work well at all. There are also internal problems like if a package breaks it can be a nightmare to fix if the dependency manager gets in your way, which it does. It's like the dependency manager thinks it is smarter than you and can do things better than you, and in many cases it is right, but sometimes it messes up bad. Maintaining all the dependencies is a issue too, it takes time and man hours and the benefits are not very clear, IMO.

There really aren't many issues with dependencies on Slackware, most are already installed, or can be installed rather easily. The problem comes with packages from GNOME, where there are hundreds of interlinked dependencies. If you try to install GNOME packages on Slackware you will see that it is a pain. Luckily there is no real need for GNOME, so this can be avoided for now. In the future if things change for the worse, you never know.

When compiling a program, it will tell you what dependencies it needs and what is optional. You just check if you have them all and if not you install them and then you install your program. I prefer this method because it keeps things light and fast and stable. I look for programs with minimal dependencies or ones that I already have. There are many programs with use lots of random dependencies ... these are typically programmed by people who don't know what they are doing, and as such the program will probably not be stable. Also, with more dependencies you get more unnecessary complexity, which is never to be favored over simplicity.

Typically, you will have a core set of dependencies for each desktop environment, or you can just look for apps with minimal dependencies and that are light and fast and use them with any window manager (what I do). So, you would either stick with KDE and dependencies for it are already taken care of, or you do what I do and use one of the lighter window manager plus some light programs that you find around the net or that are installed. There is no need for the excessive complexity and numerous dependencies of GNOME.

1 members found this post helpful.

The advantage for me, as a Slackware user, is that it makes it easier to upgrade to new versions of individual packages.

1 members found this post helpful.

Like others have said dependencies aren't much of an issue if you do a full install. And with slackbuilds.org you have a wide range of packages to choose from and it tells you the dependencies you need which can also be installed from slackbuilds.org.

Being in control of your system is the key thing. Knowing what you have installed and why you have it installed is a great thing. Since I've been using Slackware I've never ran into a "dependency" hell scenario. I have in the past with other distros. Slackware puts you in total charge of your system. It's kind of refreshing.

Between slackbuilds.org, slackpkg, pkgtools and sbopkg, package management is a breeze. It's not nearly as rough as people make it to be.

In the first place every distro out there relies on manual dependency resolving. On distros with DR it is usually done by the package maintainers. The package maintainer has to figure out which dependencies are needed and adds the list to the package. So actually, your computer does not the DR, it just looks up that list and downloads the needed dependencies (and begins at start with those packages). There are two things here that take the control away from you:
1. Optional dependencies: The package maintainer decides which optional dependencies he wants to build his packages with. After he has done this those dependencies automatically loose their "optional"-status, because you need to install them on DR systems, regardless if you want to use them or not. otherwise your dependency tree would break and the package manager would refuse to work until this is solved.
2. Dependencies that are not optional, but don't break the package if they are missing. For example, lets assume there is program A that has a GUI and a non-GUI part. The non-GUI part, for example a library can work without the GUI part. If you just want to use the non-GUI part on a server without GUI this is easily done in Slackware. On DR systems the package manager would automatically pull in a GUI, because it is marked as dependency.

There is a third point, that is indirectly caused by the lack of dependency handling in Slackware: Slackware's package format is dead simple. Ever tried to make a proper DEB or RPM package? Not comparable at all with the easiness to make Slackware packages. This goes down to the point that you can easily re-compile Slackware packages with the options you need. For example, libcaca in Slackware is compiled with imlib2 support disabled (which is normal, since imlib2 is not part of the repository). Since i need libcaca with imlib2 support I just download the libcaca part of the Slackware source tree, change the option in the build script, run it and install the the new package. After installing imlib2, of course. Done.

See it this way: In DR distros you are a mere user of the package management system. In Slackware you are the maintainer of your own personal flavor of Slackware. The positive sides of this approach outrun the negative sides by magnitudes. At least in my opinion. Coming from Debian to Slackware I couldn't believe that also in the beginning, but now I really appreciate this.

5 members found this post helpful.

A few points regarding DR:

DR is nice when it works, but can be harder to resolve when it doesn't. I use Ubuntu at work (it's our official dev environment, and our build process depends on some ubuntuisms, so I have to use it), and from time to time apt-get coughs up cryptic error messages like:

.. and seldom much else. It's a PITA to figure out what the problem actually was, or whether it was really a problem at all, let alone fix it. When you install dependencies by hand (which isn't that hard -- you look in the package's README, see what it says you need, get it, "configure ; make ; sudo make install") you immediately know what went wrong.

Another point is that Patrick + friends have already resolved all of the dependencies for the official Slackware packages for you, so there is no need for DR as long as you stick with the supported packages. This is an often-overlooked advantage of the "static" distributions like Slackware and RedHat -- all of the packages are tested against each other before going out the door, which means installing a supported package will not give rise to unforeseen problems (else it would have been observed during the QA process, and addressed). Dynamic distributions like Ubuntu cannot be tested like this, because packages get upgraded piecemeal.

This exhaustive testing is one of the things that makes Slackware a rock-solid environment. When you start installing untested packages, that advantage starts to unravel.

Finally, note that dependencies aren't a black-and-white matter. There are hard dependencies and soft dependencies, like SpiderMonkey's "dependency" on libreadline. It will take advantage of libreadline if it's installed, but will work if it isn't. An automated tool like apt-get isn't going to know whether you'll be needing to use libreadline with SpiderMonkey, and will have to guess. If you need it but it doesn't install libreadline, then you'll be an unhappy camper and will have to install libreadline and rebuild SpiderMonkey from scratch anyway. If you don't need it, but apt-get decides to install it, and runs into problems installing libreadline, then you get one of those cryptic error messages I mentioned earlier and installation fails. You end up blocked on something you don't want and don't need.

Mind you, most of the time apt-get's DR works, but the longer you use it, the more certain it is that you will eventually run into problems. So it becomes a question of which is better: (1) Sticking with the supported packages and never having to deal with DR at all (directly or indirectly), or (2) going through a little extra effort to do things manually and never running into a problem you cannot solve, or (3) having it easy most of the time and occasionally falling afoul of confusing, frustrating, potentially unsolvable setbacks.

Personally, I'm forced into option #3 at work, and opt for #1 for my own server systems (where stability is of utmost importance) and #2 for my desktop and laptop (where a little instability is, at worst, an annoyance). My life would be better, I think, if #3 were not in it.

As other people said, automatic DR puts an extra burden on the maintainer. But let's consider the user's point of view. When the distro provides 15000 packages then automatic DR is pretty much a necessity because not many people will install all of them and it will be very hard to find which package needs which other. But the packages that Slackware provides are nowhere that many. It provides packages that are used all the time and are useful for all kinds of users. That is why a full install is recommended for new users.

You can view Slackware as a mechanic's toolbox. It contains all the necessary tools to do the job and because the toolbox is not heavy, you can carry it around without taking some tool out of it. So, if you always do a full install, you don't need dependency resolution.

Because the number of packages is not that large, after some time of using Slackware and reading the changelog and stuff, you can pretty much remember the dependencies of important packages and so automatic DR is not a problem. If Slackware had 15K packages then of course nobody would be able to remember every dependency.

As other people said some dependencies are optional. But even for mandatory dependencies, there are some cases that the dependency is only used by some component and not by the main program. Let's consider KDE for example. It contains many "plugins" that provide a variety of functions. Some plugin needs samba for viewing network shares, another needs sane to access a usb scanner, etc etc. Not having automatic DR, permits me not to install some of these dependencies. Since i don't have a scanner, i can omit the sane package and while the plugin for scanners won't work, KDE will work fine. This is not much of an argument since disks are huge today, but not having automatic DR doesn't enforce things on you and gives you more freedom to do things your way.

not again...

1 members found this post helpful.

More good points by TobiSGD.

Basically, DR means more burden on the distro maintainer(s) and for no good reason. The only time I have ever gotten into dependency hell was with GNOME packages which I now avoid like the plague.

So moving the burden off of the maintainers is a good thing? How exactly? It just makes them less diligent.

Don't get me wrong, I am used to things as they are now, even if they can be bloody infuriating at times, but I wouldn't, for instance, buy a car and then have to brew my own petrol for it. I would expect the petrol to come ready to use with all of it's constituent parts already in the mix.

So why not software also?

It's fair to say that time spent trying to get dependency bugs fixed is time that could be spent fixing other bugs.

All the parts are in the mix, though. The petrol you're putting in your vehicle is a "full install". You wouldn't expect to put just one component of gasoline into the tank and have the car find a way to add the rest.

7 members found this post helpful.

And it is greatly appreciated. But that's not to say some DR would not be equally so.



All of the parts are in the mix because the developers of the petrol make sure they are there, so no, while you wouldn't expect the car to determine if other things are needed were that not the case, neither should you expect the end user to.

I appreciate that DR is a very difficult subject, and as I said, I am used to the way things are done. But every now and then I do wonder whether my time could be more productively used working rather than configuring.

May sound harsh, but nobody expects you to use Slackware. If you want to have DR on a Slackware like system, why aren't you using Salix or Vector?

I always wonder about such statements. What exactly is your work that it needs you to configure the system all the time instead of just working? If you aren't a sysadmin then the configuring part should be done when you have installed the system and all programs you need. If you are a sysadmin it is pretty easy to come up with solutions for yourself that save time when you have to install/configure a huge amount of systems.
It is not that you have to configure things for two hours every time you start a Slackware machine.

8 members found this post helpful.