why does slackware's package manager purposely not resolve dependencies?
 

(disclaimer: I use Debian, not Slackware, so forgive any factual errors here)

I was reading in a blog that Slackware's package manager doesn't resolve dependencies and that it is a completely intentional thing. So do you just manually install 60+ dependencies if a program requires them? or is there a separate Slackware program that does dependencies instead of the PM?

I get that Slackware is trying to stay true to the original Linux style, but this seems like a sort of dumb thing to not even include optionally.

Not only is it NOT a dumb thing, it is an unequalled feature and tremendous benefit!

I cannot understand why other distros encumber their users with automatic package dependency checking and take that basic capability away from their users!

In general, you never encounter 60+ depenencies when building this way. The torrent of dependencies is, in part, caused by the auto-dependency checking systems!

as a debian user, you are used to packages being split into parts

e.g. *-dev packages, and sometimes *-lib packages, as well as headers, and various other files necessary to have a complete linux installation that are not included in a default debian install

slackware does not do this

when you install, for example, python in slackware, you get python, not python-core or some other stripped down version as like what debian does

this makes for a lot less trouble with dependencies since you don't have to track down what "developmental" version of a package contains the actual program libraries

of course there still are dependencies to applications, but nothing anywhere near like the debian way of handling packages, and these dependencies are fully documented

I've never run into anything close to a 60 dependency hole.
The "dependency hell" thing is way overblown. Some blogs and reviews have you thinking its a 2 day process to find dependencies and build any program in slackware. This is not true.

It also seems easier to keep track of why certain packages are on the system.

You should give slackware a try and see for yourself.

is there actually some occasion where you would want to install a program but not the dependencies it requires?

I was actually thinking about that, but I only have a 13.0 disc and not a 13.1 (can't download it due to my location). The package management thing was the only thing really keeping me from it. Didn't realize that slack packages worked differently

A very old debate--and not one likely to ever be resolved. You simply have to choose between total control and convenience.

I would like to tell you that I have never had a problem with package management on Arch, but I'd be lying.....What is true is that--on balance--I operate more efficiently setting up and maintaining an Arch system than I ever did with Slackware.....YMMV.

If I put in the effort to become proficient on Slackware, would I change my opinion? I don't know.

Since Debian and other similar distros have binary repositories (for the most part), you must suffer through what they have chosen to include. If there is an optional dependency that is not required but was linked against when building the package, you now *must* install that dependency, even though it is optional at build-time, because the package maintainer chose to include it. Likewise, if there is an optional dependency that you *want* that *wasn't* linked against when the package was built, you must now recompile the application yourself, which either throws off package management or necessitates that you create Debian control files that inform the package manager of the added dependencies. Let's take JACK, for example, which is an optional dependency for many audio applications. JACK is not exactly light weight, so if everything includes it, then there's a lot of extra overhead (though most apps would let you choose the run-time sound server anyway). If something was not compiled to include JACK, yet you want JACK support, then you must recompile it -- and the same goes for *every* other audio package that does not include JACK support. This gets very tedious and ends up taking just as long as compiling everything in the first place.

The key here is *optional* dependencies, and that is why dependency resolution fails in my opinion (at least for strict system administrators). I know I try to avoid gconf like the plague -- some applications have the *ability* to use gconf but do not *require* it, but in Debian I can guarantee that any application that can use gconf -- was built to use gconf. Aside from that issue you can get into issues with one application requiring a newer version of a library that breaks an application that requires an older version of that library. This *can* happen in Slackware too but usually this is a problem of linking against different mutually exclusive versions in binary packages (ie they were built on different systems or at different system states), and if it did happen on Slackware then the problem would be obsolete code (and thus would affect all distros). The application would need a patch. On Debian you're just stuck and you have to recompile the app or wait until the issue is resolved. I have been hit with that dependency hell on embedded Linux and recompiling on an old ARM CPU is not fun.

They're two different philosophies. You can get up and running and just grab software (and its dependencies) a lot faster on Debian and other distros. But when it breaks (and it certainly can)...you're in for some fun. And you also lose that control over optional dependencies unless you want to recompile everything anyway.

The best solution in *my* opinion is to have a dependency-resolving *source-based* package manager that allows easy inclusion/exclusion of any optional dependencies (and there are certainly Linux distros or other OSes like BSD that attempt to do just that).

Well, that is not a straight-forward question to answer because it does not differentiate between two different "classes" of dependency.

In fact, few of us ever think to point this out separately, but it is always present in the various discussions of package managers and package dependencies - even in this thread!

What are these two classes of depencency?

1. Build time, actual source dependencies.
2. Package manager, pre-built package dependencies.

The two are not the same.

The first type is the set of all libraries which must be present to successfully build the application from it's sources. As pointed out in other posts here, some will be required to build, others will be optional - such as gconf and friends. So if I build a package that "can" use gconf, but for which it is optional, then I choose whether to include it or not myself.

The second is the set of packages that were present when a binary package was built - which is the combination of the choices made by the original builder, plus (often) other packages which may not actually be required, but were specified as dependencies by the packager, for various other reasons.

So, if we phrase the question as, "is there actually some occasion where you would want to install a program but not include all it's options?", the answer is ABSOLUTELY! You can do that with slackware, but generally not with auto-dependency package managers.

Or, if we phrase the question as, "is there actually some occasion where you would want to install a pre-built package but not the dependencies it requires?", the answer is still ABSOLUTELY, but it is generally not possible without building the program from source yourself.

Yes.

Even if you only have a [slightly] older slackware disk the idea will be pretty much the same.

You should install a virtual machine and poke around with slackware.
And other distros as well.... don't take our word for it ;)

Hi, i always wanted ask a Debian user..
What do you do when your distribution which supposingly ships so many binary applications, the users arent required to get their hands dirty, doesnt ship a free and open source application you want to use?

For example there is an excellent collection of more than 1000 solitaire games called pysolfc http://pysolfc.sourceforge.net/ which is the continuation of pysol which was removed from your distribution a long while ago cause its unmaintained, and there is a request for more than a year to include pysolfc http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519752

Would you be willing to learn how to make .deb's?

You are also left at the mercy of the quality of the database of dependencies. I have on occasion tried other versions of linux to see if the dependency tracking has improved. How I do this is install the minimal system and then ask the package manager to install openoffice.org. In able to do this it will have to install X then a desktop environment and then the document processor.

What usually happens at this point is that it fails because version X of program A requires program B to be version Y and it grinds to a halt. If you then update program B then that breaks programs C,D,E,F etc.

So automatic dependency tracking is not always the best option.

samac

I was a Fedora user before Slackware. When I needed a program, all I had to do was simply "yum-it" and the program was there. I use Linux mainly because of the Science/Math programs support and I have to use 4 programs: GNU/Octave, Maxima, sciDAVIs and LaTeX. When I needed those installed on Fedora, it would simply solve the dependencies and install it - the problem was that the dependencies were about 80 packages! Including those I didn't want and would never use (Veusz comes to my mind, now). But, that was ok, since I needed the programs. But, sometimes, when the package were updated, it comes with newer dependencies, and I asked to myself "what happend to the other dependencies? Obsolete?" and by the end of the month the system was friggin' huge!

Then I went to Slackware. First thing I thought was "well, will need a week to install those programs" and there I was, downloading the program's sources. For my surprise, I needed only 22 packages, for all those programs, including them. The other thing was the compilation - I always compile programs specific to my machine capacities and, believe me, for math purposes, this matters - and the programs run better when compiled by hand than those distributed by the repositories. So, from my specific point of view: no, it's not a sort of dumb thing, it's you being in control of your system and getting only the best for you. If I could do this in Fedora back then, I would.

About time? I spent a day compiling all those programs.

Before Slackwware, I used a Fedora-based distro. I'm (almost) certain there was an rpm command which allowed one to install a package ignoring dependency requirements. Does Debian have such an option and do people ever use it?