-   Slackware (
-   -   Why lack of dependency resolution is a "feature". A personal story. (

sombragris 05-16-2020 03:47 PM

Why lack of dependency resolution is a "feature". A personal story.
Some folks usually see dependency resolution as something good in Slackware, and there are even tools who perform that task for package management. Good for them.

It is usually said that Slackware's lack of dependency resolution is not a bug, but a feature. And I concur with that sentiment. One of the problems with dependency resolution is that it can be abused, and I would add a personal story to back that. Of course, this is anecdotal and YMMV.

Back in 2003, I was distro-hopping. I was using Mandrake Linux (for two years now) and began using Slackware; with hotplug now I was able to run a Slack system without painful setup work. The fact that Slackware began offering the latest unmodified KDE 3 was also a big plus.

In September 2003, Mandrake Linux 9.2 was released. I duly got the ISOs (painful task downloading them under near dialup speeds) and after that I upgraded my existing Mandrake workstation. With some fiddling, I was also proudly able to boot into a framebuffer console. That gave me a "penguin logo" bragging rights as well as a console taking full advantage of my 1024x768 resolution instead of a puny 80x25 character console.

But there was a problem. On each framebuffer tty screen there was an ugly "9.2" overlay at the lower right quadrant of the screen. That was downright awful and distracting. I knew I was using Mandrake 9.2; didn't need any stupid reminder of that on my screen. Typing "cls" didn't do the trick...

So I hunted down the culprit to a small rpm package whose name I don't remember now. Great!! I thought. so I told Mandrake's RPM Manager (urpmi) to remove the package.

Well, urpmi said "great but we'll have to remove all these packages..." and it basically said it would have to remove X11 and the whole graphical desktop shabang. KDE, GNOME, IceWM... you name it. A humongous list of packages. That's right: the stupid "9.2" framebuffer overlay was listed as a dependency of X11 and whole graphical package groups.

This was obviously an artificial dependency created by packagers. Options? I would have to edit the SRPM, recompile.... or tell urpmi to force ignore dependency resolution and just remove that package, and risking breaking the package index...

And thus I thought: "too much effort for some stupid advertisement"; because that overlay was that, a stupid advertisement branding, and completely unnecessary. So, I grabbed my Slackware ISO, wiped my Mandrake Linux installation, and began my full-time Slackware journey. I anticipated the learning curve to be steep after switching from a supposedly "beginner-friendly" distro, but it wasn't. The community was welcoming and folks were delighted to teach me the Slackware ways when I needed it.

Now, with Slackware I would not have any of those stupid adverts, at all. When I install a package from SBo I always keep note of the dependencies and manually satisfy them. No problem at all except with python and perl packages, which are their own version of dependency hell... :D

So, folks, this is why I think that lack of dependency resolution is a feature and not a bug. Cheers!

drgibbon 05-16-2020 04:34 PM

I don't mind lack of dependency resolution in core Slackware, those packages are just meant to be installed en masse and minimally updated anyway. But not using dependency resolution for SBo seems to me like needless work that is better off delegated to a machine. sbotools strikes quite a nice balance there, sbopkg has its queuefiles, but each to their own :)

upnort 05-16-2020 04:43 PM

Good story and explains my primary complaint about dependency resolution.

Using dependency resolution is a must in large scale binary repositories when installing packages. Dependency resolution pulls in all of the required packages. This should be a no brainer.

When removing packages the only desired result is removing that single package. Yet all of the package managers do not do this. Instead all dependencies are removed too.

Slackware is the only system I have used that supports this in a sane manner. The removepkg tool does not blindly remove files and only removes files that are not duplicated in other packages.

I still have my original Mandrake 9.0 CDs from 2002. Not my first distro but the first that I paid for. The Mandrake design was way ahead of other distros with respect to creating an operating system for less tech savvy users.

Yet I remember urpmi frustrating me with breakage, although to be fair, possibly many of those issues were caused by dial-up. I remember the dependency resolution issues described, which back then I soon noticed affecting all distros I tested. To this day I don't understand this design.

Those kinds of issues redirected my focus toward Slackware. Initially I did not find Slackware easy, but the big attraction was nothing getting in my way and there were no presumptions about how I should use my computers.

Slackware remains designed that way and I am grateful.

mralk3 05-16-2020 06:12 PM

The best part is that Slackware creates a standard installation with all the tools needed to easily be extended. Its great to have the option to make the system whatever you want it to be without having to install -dev packages or "recommended" dependencies. As a web application developer, I find it very difficult to switch to another OS, because Slackware is so conveniently wrapped up. I am able to do the programming (ruby), testing cycle (TDD and BDD), QA, packaging, and distribution of web apps without deviating too far from a stock installation of Slackware. Other Linux distributions require a lot of jumping though hoops to achieve the same stock environment as Slackware.

Didier Spaier 05-16-2020 06:24 PM

I am also a former Mandrake user, but don't remember why I switched to Slackware (10.2 IIRC).

Maybe some of us remember that Slackware once had dependency resolution using swaret?

Anyway Slint does have it through slapt-get. But we advise users to only use removepkg to remove packages, never "slapt-get --remove". I even consider just removing this option from the slapt-get we ship, although I be not aware of an issue about that reported by Slint users.[1]

Anyway what should be in a dependency list is relative to which packages were installed at time of buillding the dependent software, the options used when building it and the scope of the resolution: should we include build dependencies, dependencies not detected by ldd like pyhon, ruby, perl or shell scripts etc.? So a dependency list can't be perfect. But as long as it is good enough to bring all packages that a user needs in this user's use case, nobody will complain.

hitest 05-16-2020 06:31 PM


Originally Posted by Didier Spaier (Post 6124056)
I am also a former Mandrake user, but don't remember why I switched to Slackware (10.2 IIRC).

I'm also a former Mandrake user. I started using Slackware on version 10.0 in 2004. I started using Slackware when Red Hat stopped offering their free version and moved to RHEL. Many thanks to Red Hat for encouraging me to move to the best OS on the planet.

gus3 05-16-2020 07:54 PM

I never minded working through "dependency hell" in Red Hat, Mandrake, or SuSE. It was usually for a one-off situation, and once it was resolved, it stayed resolved.

Gentoo, OTOH, completely fell apart for me when an update to libffi failed, wrecking the gcc update, which then meant no further updates were possible. Eventually, I wasn't even able to back up my home directory in preparation for a wipe/install. I lost a lot of files.

It's Weinberg's Second Law: "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." It's in the fortunes database:

$ fortune -m woodpecker

willysr 05-16-2020 08:09 PM

Good to know that some of us were Mandrake users too. I also started my Linux journey using Mandrake and i was one of theit VIP member too since i helped the translation project into my native language.

I moved to Slackware in 2005 when i bought my first laptop and mandriva always ended up in kernel panic and so did other linux distribution at that time, except for Slackware. Since then, i never looked back.

Regarding lack of dependency resolution, i also agree that it's a feature since i have been managing some machines using Ubuntu and while apt makes it easier, sometimes you see hell of packages gets installed which in my preference i don't need them.

sombragris 05-16-2020 08:20 PM

Thanks to everyone for their responses. It is good to learn about different backgrounds and approaches to system administration.

I remember swaret and even now (as Didier pointed IIRC) one can use slapt-get or similar tools, which are fantastic if one likes the concept of dependency resolution. Thanfully these remain optional :)

TheRealGrogan 05-19-2020 04:09 PM

I HATE dumb assed package dependencies like you describe.

I once had a mishap with apt-get on a Linux Mint install that I was going to use for games. I guess xorg were Mint packages, and xorg-devel was a Debian package or something. I went to install xorg-dev and it showed me that it was going to remove all these xorg packages, including the X server. I thought "it's not really going to do that, that would be retarded" and I proceeded, expecting some sort of resolution when it actually came to it. Sure enough, it removed xorg packages and didn't even install an X server. It was unfun fixing that :-)

Another experience I hated... on Manjaro (mostly Arch with delayed update cycle) I wanted to remove Plasma 5. It was pretty difficult, due to seemingly circular package dependencies. I ended up forcing some recursive, cascading pacman commands and reinstalling packages that I didn't want removed. Even after that, pacman kept trying to put some KDE related packages back so I had to add IgnorePkg directives until I figured out what else I had to remove. (Some of if was being caused by parts of this Octopi package manager I think)

On good old Slackware, such things are as simple as using removepkg with wildcards until you get things how you want them. So yeah, for me too it's a "feature".

Didier Spaier 05-19-2020 04:41 PM

Some folks just don't realize that dependency resolution's purpose is mainly to find which packages need to be installed for another one to run, not to find which packages to remove if a dependency is removed.

In Slint, users run slapt-get with its dependency resolution feature to install packages, but removepkg to remove packages. It works, and no one complained about dependency resolution so far. Similarly, users are advised to run "sqg -p <package>" to build a queue file then "sbopkg -k -i <package>" and choose the queue to determine which packages to build and install, and in which order, but still removepkg to remove the packages

Indeed dependency resolution is useful to know which packages would miss a dependency if another one was removed, but it is up to the user to decide if the dependent should be kept or removed. Even more so as accuracy of this information can never be guaranteed.

PS And don't blame the hammer that hits your finger instead of the nail's head...

drgibbon 05-19-2020 04:53 PM


Originally Posted by Didier Spaier (Post 6125096)
Some folks just don't realize that dependency resolution's purpose is mainly to find which packages need to be installed for another one to run, not to find which packages to remove if a dependency is removed.

The sboremove command from sbotools can be pretty handy, since it will only offer to remove installed packages that nothing else explicitly requires (an extreme time saving example would be `sboremove pandoc`). But like you noted after, it's not guaranteed. It's possible that a package is not requirement of other packages but is an optional dependency of something else, in which case you actually want to keep it. Maybe a rare case, but it's good that sboremove allows for user control.

Poprocks 05-20-2020 09:28 AM

Dependency checking/resolution is a good concept in theory, but in reality I think it introduces more problems than it solves. I'm not going to get into all of the usual reasons for this - PV explains many of the pitfalls with dependency checking in his interview with TLLTS from 2006. Most if not all of these still apply today.

For me, one of the biggest problems with dependency checking is that most systems rely on a database system to keep track of the dependencies. One problem with databases is that if they break or become corrupt, it can be very difficult and in some circumstances impossible to rebuild it without losing data. So users can become frustrated as they are no longer able to remove or add any software to their machines, including performing sane updates, so they fall back on my absolute pet peeve - they decide to reinstall the OS.

I have never reinstalled Slackware - not once, on any of my devices. There is no need whatsoever. Even though PV describes the files in /var/log/packages/* as "database entries," they are just plaintext files, and not type of binary database I am referring to. PV's method fits better with the UNIX philosophy - everything is a file, and each tool should do one thing and do it well.

As well, encouraging users to do a full install -- which will of course inherently have no dependency issues -- and basically using that as an across-the-board assumption when providing support, provides a consistent base. It is so much easier to provide assistance to users when we know they at least have a certain base set of packages deployed (plus or minus a few package groups, mainly kde, kdei and xfce).

Personally I'm an sbopkg user and not sbotools, but I have no problem whatsoever with a separate dependency tracking mechanism for third party Slackbuilds. At least if those break and the user is unable to fix it, the base system and its package manager will be unaffected.

Didier Spaier 05-20-2020 11:04 AM


Originally Posted by Poprocks (Post 6125344)
For me, one of the biggest problems with dependency checking is that most systems rely on a database system to keep track of the dependencies.

slapt-get only relies on on lines added to the files PACKAGES.TXT beginning with:
and as far as I know PACKAGES.TXT is just a text file ;)

chrisretusn 05-20-2020 12:59 PM

The biggest benefit of the way Slackware handles dependency checking is, it is my responsibility. Many years ago when I use to distro shop, my biggest frustration was how dependencies where handled in those other distributions. Like the making separate packages for compilation and what I call the kitchen sink principle. Just include everything in to the package set that "might" be needed. You want to install one program and a boat load of baggage is installed along with it, sometimes including upgrades to already installed packges, that really wasn't necessary, so that boat cascaded into a supertanker. This madness as I call it, always drove me back to Slackware.

With Slackware, for third party programs, I am in total control of what is dependent or not. I build it my way. It is very rare (with -current at least) that an update a to base Slackware package is needed to install a third party packages. In fact I cannot recall a single instance where I have had to upgrade a base Slackware package. Modify the SlackBuild? Yes, I have one such package installed on my desktop; cups modified to use avahi. My biggest dependency hell I tackled was the dependencies for perl-Finance-Quote, the satisfaction of getting that all done was worth it. It's the fun of using Slackware.

All times are GMT -5. The time now is 01:30 AM.