Re: what's slackware like for the minimalist?
Yes. It is the responsibility of the person installing a package to assure that dependencies are met. Of course, Slackware provides all the dependencies for software included in the installation; so the main concern is when installing "third-party" packages.
Originally Posted by SomeGuyDude
The site from which you obtain your third-party package should list the dependencies for you. As an example, vobcopy specifies that you will also need 'libdvdread' and 'libdvdcss' (the latter is actually only needed for encrypted DVDs). The same site will typically provide the dependency packages as well (I have never encountered otherwise), but the onus is on the user to download and install them.
With Slackware, you WILL have to "root for" and install dependencies manually (unless you use one of the add-ons such as 'slapt-get' or 'slackpkg'), however, one shouldn't assume that Slackware installation entails "boatloads of dependencies" just because the corresponding installation in Debian or Ubuntu does.
Originally Posted by SomeGuyDude
Slackware packages are, with very few exceptions, unmodified versions of the software as provided by the upstream projects; and upstream projects generally try to minimize the number of their dependencies. This is a different from the Debian philosophy of splitting projects into multiple packages in order to provide better granularity.
One area this granularity is exhibited in the fact that SW packages always include the documentation and development files as provided by the upstream project. There is never a need to install a separate "-dev" or "-doc" package (or any "build-essentials" either).
More importantly, the Debian philosophy seems to encourage a proliferation of packages (and thus dependencies). Whereas Slackware (packaging the software as provided by an upstream project) requires 3 packages for an OpenOffice install, Debian has separate 145 packages. Slackware requires 3 packages for ALSA, Debian has 41. Slackware requires installation of a single Apache package, whereas Debian provides 146. Slackware has three kernel module packages, whereas Debian breaks them down into 250 different packages.
This is not to disparage Debian's approach to packaging, just pointing out the differences. Slackware's approach is definitely more wasteful of harddrive space -- I would estimate that about 20% of the data in a full Slackware install is never used (dev files, documentation, unused drivers/libs, etc) -- and the statistics I provided are for the most extreme cases (more typically, a single Slackware package is equivalent to about four or five Debian packages). Nonetheless, it should be noted that a "boatload" of Debian dependencies does not correlate to a "boatload" of Slackware dependencies.
Manually fulfilling dependencies can indeed be troublesome at times. This is especially true for installation of GNOME-based software (as SW does not officially support GNOME). Installing AbiWord, for example, requires that seven other packages be installed. If you're intent on running GNOME, Slackware may not be the best choice of distro for you.
Another area where you may find yourself needing to fulfill a large number of dependencies is with multimedia programs (for example, the Kino video editor has about a half dozen dependencies which need to be met). The caveat to this is that, as you fulfill the dozen or so basic dependencies supporting multimedia, installing additional MM packages requires less effort. Personally, multimedia is one of my main reasons for preferring Slackware; I have to install about two dozen packages of applications, libraries, and codecs but I end up with the latest versions and I'm quite knowledgeable about what my system is capable of.
Also, since I often choose to compile and build these multimedia packages myself, I know what the configuration of programs such as FFMPEG, MPlayer, or VideoLan is. This can be important because such "applications" are often employed as "libraries" by other MM applications. It can be extremely frustrating trying to figure out that an application is not working owing to inappropriate configuration switches having been used in creating a dependency's package. This problem is not addressed by APT and RPM package managers and error messages generated are rarely instructive to the user. (Neither does Slackware resolve this problem, however, having created the packages myself, I am able to avoid it or at least recognize it.)
Other than GNOME apps and multimedia, Slackware provides a fairly complete set of programs and their associated dependencies. Since your Slackware system is basically configured exactly the same as the developer's (as opposed to Ubuntu where the typical user installation does not include all the software employed by its developers), updating versions of pre-installed programs/libraries becomes trivial; especially so since you can rely on the vanilla source code from the upstream project not conflicting with other packages.
With Slackware, you can rely on the fact that practically no errors will have been introduced by the distro packager* and that system error messages will accurately report the true nature of the problem. Of course, this is the ideal sought by all distributions, but using a dependency resolving package management system involves a lot more people, a more complex approach, and a much greater chance of errors being introduced by the process.
* I recall once about 8 years ago that Patrick had the permissions set wrong on a file in a package. That is the only "Slackware" bug I have personally ever encountered (though I imagine others have occurred).
"We visited sixty-six islands and landed eighty-one times, wading, swimming (to shore). Most of the people were friendly and delightful; only two arrows shot at us, and only one went near -- So much for savages!" - J.C. Patterson