yes it's called dpkg and is the equivalent to rpm

Let me disagree. I guess it appears that there are two different philosophies.

What actually happens is that different techniques work best under different circumstances and there is strong temptation to use that which works most of the time universally.

You may use the following model of Slackware creation to understand the choices.

1. Create a team of developers small enough to have no managment problems. Slackware is not Patrick's one man project, but the team is small and it can be seen through quality and integrity.

2. Include some most basic software configured the most reasonable way.

Most other distros provide equal customization options on all levels of software. Slackware is different. Even though it is easy to modify it, you are not expected, or at least encouraged, to do so.

3. Check if your team can handle more. If yes, go back to step 2.

No dependency resolution automation is necessary so far since it is required to handle each and every dependency manually inside the team and everything is always satisfied outside it.

In fact, there is rudimentary dependency resolution - packages are grouped so that KDE, or X, or GUI applications, or TCL, and so on, can be installed or skipped by the installer. What depends on what is evident so no need for formal tracking.

4. Decide how users will add more software. Currently the most usual way is to create a bash script that compiles software and makes a package. Such scripts are called Slackbuilds. People share both them and resulting binaries. I heard there are projects that introduce dependency resolution at this point, but I never had any intention to find out the details.

5. Check if that works. This is very different from the Debian or any other dependency resolution based approach which, with enough features like circular dependency handling and from mathematical standpoint, is guaranteed to work. Slackware approach well may fail, but in the current state of the Linux universe it works for, I guess, just 3 reasons.

First, Slackware is big enough for many applications to have none or few dependencies outside the basic distribution. If there are dependencies it is just written down in plain English that this slackbild depends on that slackbuild. For example, the audacity slackbuild description reads:

"Audacity requires wxPython or wxGTK and libsndfile, both of which are available at SlackBuilds.org. This script builds with support for libmad, libvorbis, id3tag, and libflac (all of which are included in stock Slackware), but they can be removed in the "configure" section of the build script if desired."

I doubt adding or replacing anything is necessary here.

Second, if Slackware people care about an application, they care a lot. They modify there pet application, use different libraries, compare versions, and still want the package manager to keep their system clean. So, they want to be free from dependency resolution.

Since one physically cannot care about (or even professionally use?) many applications, the lack of dependency resolution does not create any problems. If it is not the case, like there is the "I try everything I hear about" obsession aggravated with the "latest NOW" approach, Slackware user is more likely to double boot some other distro than to think about modifying Slackware.

Third, Slackware users agree to use and, more importantly, make big, like VLC, and huge, like GNOME, slackbuilds. I am not a psychologist to explain why that happens, but I feel there must be some correlation with other factors that make people choose Slackware.

An interesting claim. "Directly", I work with the following programs on this machine: vim, gcc, gdb, nasm, screen, rxvt-unicode, xpdf and firefox. I would like to perform an installation of Slackware that will allow me to run the previously mentioned programs yet not install all sorts of extra packages (i.e. packages I don't need). According to you, the required dependencies of the programs I directly use should be evident. If so, could you please list them for me?

Yes. I believe you would. I prefer to manage my own dependency issues, I know what is going on in my Slackware system. I find that our package management system is robust, and reliable: I trust pkgtool and slackpkg.

I have used Arch several times and pacman is a nice package manager, but, in my opinion Arch is too bleeding edge for my tastes. If I want bleeding edge I run Slackware-current ( I maintain one -current box on my Slackware LAN).

If you really want to know have a look as the SalixOS dependency files. The nice people there have done all the work for you. http://download.salixos.org/x86_64/slackware-13.1/deps/ These are the dependencies for the Slackware packages that SalixOS-13.1_x86-64 uses.

samac

I don't really want to know, I'm trying to prove a point.

That would be doing your work for you.

If had some odd desire to do just that, I would install a minimal slackware system (via the installer menu choices). I would then use grep on the package descriptions to find the packages containing the executables that I want and install them. Attempt to run the executable and look for command line errors. Install the package(s) required to remove the error. Repeat until complete.

There's your algorithm.

What work? I have no intention of installing Slackware. My post had the sole purpose to prove that "what depends on what" is not evident.

So WTF are you doing commenting here then? (What is it about the dicks that use other distros? I don't go post sh*t on their forums. Jesus.)

BTW, "what depends on what" is evident. There's no mystery about what a given executable needs. There's no mystery on how to figure it out.

You just want someone else to figure it out for you. Fine, go use a distro that does that and post on their forum threads. Slackware isn't for you, which isn't a judgment on your fitness as a human being or even as a FOSS user.

Then you will not have read the Slackbook and the section on the package series.

Your list could be fulfilled by installing the a, ap, d, l, x and selected packages from the xap series except for rxvt-unicode, which is available on Slackbuilds.org. All dependency requirements for software available at Slackbuilds.org are detailed.

When will people get the idea that Slackware is an operating system with the ability to be customised with software of your choice?

Richard Cranium: Why would I not comment here? I have used Slackware in the past, everything I say is a result of personal experience. "Possible to find out" is not the same as "evident". It's possible to find out how a keyboard works but its functionality is not something I call "evident". A lot of you Slackware users get terribly offended whenever anyone has anything bad to say about this distribution. It's pathetic. Someone made a claim I did not agree to, that is why I posted, WTF is so wrong with that? I don't want anyone else figuring anything for me, as I've mentioned again and again. I was simply replying to that person I did not agree to.

allend: Your deduction skills make me laugh. And who cares that the A/AP/D/L/X sets would fulfill my list? I might very well do a FULL install. I mentioned in the original post:

Ya know the false image of Slackware really annoys me lol, because of the dependencies and the old-school install program people assume it takes many days to setup Slackware the way you want it, honestly I can set it up as fast as I can setup Ubuntu the way I want it, software installation is really just as fast as any other distro as long as you know how to properly compile Linux software

@posixculprit - I posted in good faith based on:
You respond with ridicule and a logic failure.
which is not compatible with LMAO

I may also have the mentality of "wanting things just to work", but with a very important detail. "I want things to just work, but I want them to work RIGHT." That is why I use Slackware. I also needed audacity for some sound editing, went to slackbuilds, got the required 'dependencies' to go along with that, proceeded to build and install said dependencies myself, built and installed audacity after, and all was well. For audacity to work, as mentioned in previous posts, was either wxPython or wxGTK. I chose wxPython. The rest, I didn't even have to think about.

I would rather have to manage my own dep. for the sheer fact that I know exactly what is going into my system, and can get away with including as little 'extra' stuff as possible. I shudder to think what other 'stuff' goes into a Debian system when you want audacity, or any other software.

I see this as a matter of a way to keep 'bloat' in check.

I can complete a full install of Slackware (with all dependencies met) faster than any other distro I've ever used: Debian, Arch, FreeBSD, Red Hat, CentOS, Mandriva, Ubuntu, openSUSE, etc.
I did a full install of Slackware 13.1 yesterday in 30 minutes on my Toshiba NB200 Netbook....up and running. Wireless quickly set-up after installing wicd from /extra.