One important challenge with dependency resolution is that it places a huge burden on package maintainers. When you create the package (or the SlackBuild for the package) you have to define all the packages that it is dependent on AND which versions of those packages it can work with. That's a lot of extra work to be putting in, as these dependency lists can be very fluid and fragile. Furthermore, if you decide to change some configure flags and rebuild the package then suddenly your dependency list is all wrong. Gentoo is the only distro I've see that tries to handle dependency resolution for all possible build configurations and they have a very long and involved process for inducting and training new package managers.

So dependency management only really works if you use static, binary packages. If you don't allow users to rebuild their packages. If the upstream projects play nice with version numbering (ie, not breaking the API with a minor version bump). If your package maintainers have nothing but time on their hands to research, build and test the dependency lists for each package. Or if you have a large team of highly-trained maintainers who each work on a small subdivision of the package tree.

Slackware is not like that. Slackware is a distribution that can be managed by a single person. It has a simple package system that is easy for both package maintainers and users. It allows people to rebuild or update any package on the system with a different configuration. It allows users to install alternatives not already defined in some upstream repository. It allows sysadmins and developers who understand their systems and know what they want to install/update/modify/remove packages at will.

With an automatic dependency resolution system, as soon as you step outside the "approved" tree the whole system breaks down and becomes an albatross. It's no longer useful because it's understanding of the dependency resolution is incorrect, but it's still trying to make you conform to that incorrect rule set so it throws up warnings and confirmations for every operation.


Slackware demands more thought and understanding than other distributions, but it repays that by giving you complete and unfettered control of the package management.

8 members found this post helpful.

Slackware isn't for everyone. I guess you might not be among those it is for.

It works for me because I like to install a lot of stuff via source, either a different version, or patched source, or perhaps an entirely alternate package. With distros that manage the dependencies for me, they get all fouled up when I do that.

1 members found this post helpful.

There are women Slackers, too.

2 members found this post helpful.

This is the from the email that you get the first time you log into a new Slackware installation:

I can. If you want to replace a package with a newer one or one with different build settings, the process is easier on Slackware than on any other distribution.

2 members found this post helpful.

Perhaps a compromise to this never-ending dependency debate might help.

For myself I don't like the idea of forced automated dependency installations. My experience with other distros is often an alleged dependency is not a run-time or build requirement but instead is a fetish of the original packager.

Even if a package manager was designed to force an alleged dependency to be installed, the reverse should not be true. Removing a package should never require removing any other package. Period.

Not having dependencies being forced on me is one reason I stick with Slackware. Yet although I don't want packages being shoved down my throat, knowing dependencies is a reasonable idea that many people request. Perhaps the package manager could inform users of mandatory and optional dependencies, just not force the user to install them. Provide the information but in the Slackware tradition, let the user decide.

There has been some recent discussions of creating a tool that can inspect packages to create a dependency database. Perhaps that might be a way to resolve this debate.

Not Ubuntu, not anything. Someone writes scripts for that and includes those scripts in the repositories. For every piece of software out there there is source code, and then there is source code + scripts. An .rpm file is just something someone wrote for your convenience.

That being said, there are varying levels of installation scripts out there for slackware. I myself use the powerful sbopkg.

I decided to install devede this weekend. For the 13.37, there were only 2 dependencies listed on slackbuilds.org. I was unable to simply type
I had to type sbopkg, and then add the 2 dependencies to my build queue first. Then build. However, the entire process took the same amount of time to complete as in Kubuntu.

I guess the question is why does slackware not resolve dependencies, and the answer is it can if someone tells it to, just like any distro. Patrick and the team simply leave the choice up to us.

1 members found this post helpful.

Simply as that, download the queue-files and put them into sbopkg's queue folder (default: /var/lib/sbopkg/queues/). The next time you want to install something via command-line you will be asked if you want to build/install only the package or if you want to use the queue-file which already contains the dependencies.

1 members found this post helpful.

I don't get the big deal about this. You want to install a new program. It needs libraries that aren't on your system and you have to install them along side the new program. So what?

Oh, BTW, there is hope in the world. RPM still has a heavenly --nodeps parameter for you slackers to tinker RPM based distros to get the job done the way you want

Correct. I tried to update Gnumeric in a Debian virtual machine yesterday, from the default that comes with Squeeze to the latest source release. It wasn't worth the hassle. I felt as though pulling one thread would unravel the whole canvas. In Slackware it is simplicity itself to update Gnumeric to the latest release.
I have never found dependencies a problem from the very first day I started using Slackware. Quite the opposite - at long last I could control what software would run on my machine. Slackware gets the balance right, but I have a feeling most people don't understand this because the Slackware philosophy is a *philosophy*, not a technical issue.

1 members found this post helpful.

For you and me, and many slackers, there's no problem doing this. Just roll your own SlackBuilds (or get them from slackbuilds.org / sbopkg), resolve dependencies, compile the thing and that's it. Piece of cake.

But for many users, that's quite a difficult task. Perhaps they don't have the knowledge, or simply don't need/want to do it. I'd say such users expect the system to "hold their hand" and do all software installation tasks for them. I suppose that's why discussions as this one take place.

When I think about dependencies, it all comes down to the fact that I want to be in control of my system, I don't want a package manager to decide for me what my system should or shoudn't have.

Slackware is for those willing to exercise their gray matter.

http://www.youtube.com/watch?v=y0Fc9lvRMy0

Enjoy!

Yes, but once you start doing that you're breaking the contract with your package manager and it won't be able to accurately judge dependency trees anymore making the entire dependency resolution infrastructure next to worthless. At that point, you might as well ditch the overhead and just use pkgtools.

In IT you can always observe that the Windows admins are always busy and stressed, running putting out fires and banging their heads against the wall with obscure problems. Meanwhile the *nix admins are sitting back in the relative bliss of a sane, stable, and manageable environment.

Slackware admins make the admins of other distros look like Windows admins. The wisdom of the Slackware approach isn't always obvious at first glance, but it's time-tested and proven.

http://www.linuxquestions.org/questi...ml#post4263386

Topic closed

3 members found this post helpful.

DragonWisard said it very well.

More to the point, when I'm building a package, I generally know what's needed from the application's website or other documentation. Very often, the specifications are for some library or other package of a certain version or higher. That gives me a lot of flexibility when I build a Slackware package; I don't have to have the latest version.

However, If I want to install a new package from a dependency-resolving package manager, and that new software requires a newer version of a dependency, then it will update that package too -- and perhaps every package that was built with it. This is how a simple change can cascade, even though the software I want doesn't actually require the latest version of the dependency.

Having said that, I've worked with Fedora, SuSE, Ubuntu, and others. I've only had a little trouble with the dependency-resolution package managers.

Regards,