LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-16-2020, 03:47 PM   #1
sombragris
Member
 
Registered: Jul 2004
Location: Asuncion, Paraguay, South America
Distribution: Slackware
Posts: 512

Rep: Reputation: 255Reputation: 255Reputation: 255
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...

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

Last edited by sombragris; 05-16-2020 at 03:49 PM.
 
Old 05-16-2020, 04:34 PM   #2
drgibbon
Member
 
Registered: Nov 2014
Distribution: Slackware64 -current
Posts: 651

Rep: Reputation: 423Reputation: 423Reputation: 423Reputation: 423Reputation: 423
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
 
2 members found this post helpful.
Old 05-16-2020, 04:43 PM   #3
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS
Posts: 1,575

Rep: Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915
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.
 
2 members found this post helpful.
Old 05-16-2020, 06:12 PM   #4
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware, OpenBSD, Linux From Scratch
Posts: 1,412

Rep: Reputation: 781Reputation: 781Reputation: 781Reputation: 781Reputation: 781Reputation: 781Reputation: 781
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.
 
2 members found this post helpful.
Old 05-16-2020, 06:24 PM   #5
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,323

Rep: Reputation: Disabled
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.

Last edited by Didier Spaier; 05-16-2020 at 06:33 PM.
 
2 members found this post helpful.
Old 05-16-2020, 06:31 PM   #6
hitest
Guru
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 6,200

Rep: Reputation: 2429Reputation: 2429Reputation: 2429Reputation: 2429Reputation: 2429Reputation: 2429Reputation: 2429Reputation: 2429Reputation: 2429Reputation: 2429Reputation: 2429
Quote:
Originally Posted by Didier Spaier View Post
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.
 
2 members found this post helpful.
Old 05-16-2020, 07:54 PM   #7
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 297

Rep: Reputation: Disabled
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
 
1 members found this post helpful.
Old 05-16-2020, 08:09 PM   #8
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 4,134

Rep: Reputation: 1365Reputation: 1365Reputation: 1365Reputation: 1365Reputation: 1365Reputation: 1365Reputation: 1365Reputation: 1365Reputation: 1365Reputation: 1365
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.
 
2 members found this post helpful.
Old 05-16-2020, 08:20 PM   #9
sombragris
Member
 
Registered: Jul 2004
Location: Asuncion, Paraguay, South America
Distribution: Slackware
Posts: 512

Original Poster
Rep: Reputation: 255Reputation: 255Reputation: 255
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
 
2 members found this post helpful.
Old 05-19-2020, 04:09 PM   #10
TheRealGrogan
Member
 
Registered: Oct 2010
Location: Ontario, Canada
Distribution: Slackware, LFS, Manjaro (for gaming)
Posts: 378

Rep: Reputation: 248Reputation: 248Reputation: 248
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".
 
1 members found this post helpful.
Old 05-19-2020, 04:41 PM   #11
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,323

Rep: Reputation: Disabled
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...

Last edited by Didier Spaier; 05-19-2020 at 04:45 PM.
 
3 members found this post helpful.
Old 05-19-2020, 04:53 PM   #12
drgibbon
Member
 
Registered: Nov 2014
Distribution: Slackware64 -current
Posts: 651

Rep: Reputation: 423Reputation: 423Reputation: 423Reputation: 423Reputation: 423
Quote:
Originally Posted by Didier Spaier View Post
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.
 
1 members found this post helpful.
Old 05-20-2020, 09:28 AM   #13
Poprocks
Member
 
Registered: Sep 2003
Location: Toronto, Canada
Distribution: Slackware
Posts: 500

Rep: Reputation: 267Reputation: 267Reputation: 267
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.
 
2 members found this post helpful.
Old 05-20-2020, 11:04 AM   #14
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,323

Rep: Reputation: Disabled
Quote:
Originally Posted by Poprocks View Post
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:
PACKAGE {REQUIRED,CONFLICTS,SUGGESTS}:
and as far as I know PACKAGES.TXT is just a text file

Last edited by Didier Spaier; 05-20-2020 at 11:05 AM.
 
Old 05-20-2020, 12:59 PM   #15
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 1,133

Rep: Reputation: 467Reputation: 467Reputation: 467Reputation: 467Reputation: 467
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.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] How exactly one manages the lack of dependency resolution? the dsc Slackware 49 02-13-2015 03:50 PM
Telling people to use "Google," to "RTFM," or "Use the search feature" Ausar General 77 03-21-2010 11:26 AM
One Part Horror Story; One Part Success Story davidstvz General 3 08-25-2009 04:02 PM
Help With Java Problem Please"""""""""""" suemcholan Linux - Newbie 1 04-02-2008 06:02 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:26 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration