How do I check dependencies?
 

Normally a Debian user I want to give Slackware a try. I installed Slackware64-current into Virtualbox and now have a question. Unlike Debian Slackwares packet management tools do not check dependencies, it is up to the user to do this. I already had a look at:
Slackware Package Management
slackpkg
SlackBuilds.org
sbopkg
Slackware Basics
and all of this documentation show me tools to manage packages and that I have to do dependency checks myself.
But NONE of them explains to me how to do that. How should I know what dependencys package XYZ has?

Can someone please explain to me how I do that?

Programs will specify the prerequisites in their documentation, some are needed to build and some are needed to run.

eg. GNU gcc: http://gcc.gnu.org/install/prerequisites.html

hth

Slackbuilds.org lists dependencies in the README files.

http://slackbuilds.org/faq/#deps

Good luck. ;-)

+1 for slackbuilds.org. It really makes everything very simple. You may want to check out sbopkg which allows you to keep track of updates to packages which have been installed with slackbuilds.org.

So that means that a) I have to install a program, in hope that it is well documented, to see what dependencies it may have, or b) I have to look it up SlackBuilds.org?
Wow, I wonder what will happen if I install a program like VLC, which has lot of dependencies, and then I have to check on what this dependencies depend and so on. Maybe I am fed with a silver spoon from my experiences with Debian, but it seems to me there must be a simpler way.

Anyway, thanks for your help.

Slackware is distributed as a complete OS and there for needs no dependency tracking for its full and complete repository that you should install in full.

Anything extra you want to install is either found at SlackBuilds.org that clearly state all the extra dependencies or you may be able to find precompiled binaries at any of the other unofficial repositories.

Dependency tracking only gets in the way if you were to try and mash it together with an unofficial repository.


On an extra note. If you don't want a program on your computer because you think it takes up too much hardrive space in your 100+ gigs of space, then uninstall it. Most minor programs shouldn't harm the functionality of your system. It's mainly the library packages that would need to be kept. If you want to trim, ap/ xap/ y/ e/ and f/ are all good places to do that. I would keep everything else.

It is normally much less painful that you make it out to be. As for VLC, Alien Bob has done the work for you: http://www.videolan.org/vlc/download-slackware.html

In the rare case of VLC, Alien Bob's repository is *definitely* the place to get it. He builds it statically so dependencies are a non-issue, and you won't need to upgrade a bunch of applications to try to keep VLC in some fragile shared library state. Alien Bob's repository is a very good one for both SlackBuilds and prebuilt packages.

Another good repository for SlackBuilds and prebuilt packages: rworkman's repository.

Both of the above repositories are maintained by two members of the core Slackware team -- and thus they are quite trustworthy.

If you're looking for applications that don't exist in either of those repositories (and you will at some point, since both repositories are relatively small), slackbuilds.org is the best place in my opinion (and sbopkg is a great interface for it). Of course no binary packages are hosted at slackbuilds.org -- just SlackBuilds. Outside of official Slackware packages (and possibly the two above-mentioned repositories hosting binaries), Slackware is very much a source-based distribution. This means you can specify whether you want to include an optional dependency instead of being forced to use it (as in binary-based package distributions, like Debian). I personally dislike gconf, for example, so I make sure to exclude it as a dependency or avoid the application outright if it is a required dependency (fortunately gconf is usually optional). Another good example is JACK -- if JACK is installed, almost everything involving audio will try to build against it. You may not want everything to build against JACK, or you may not want JACK at all. In binary-based distributions, you'd be stuck with JACK unless they hosted a version with JACK support and a version without (which obviously is not a common thing to do, especially since there are many applications that support JACK). You're either forced to install JACK or you're forced to rebuild the application against JACK if support was not included. Binary-based distributions are great if you lack the time or the technical knowledge, but I much prefer source-based package management for those reasons.

sbopkg is a fantastic interface to slackbuilds.org, and makes building dependency trees very easy -- you can create a queue and build and install each package in the order specified. This means you decide what dependencies an application will link against.

Gentoo and arch are other nice source-based distributions (though they are not shipped as a 'full' OS, unlike Slackware), and they include dependency resolution alongside their source-based package manager. Gentoo's USE flags would certainly be handy in dictating optional dependencies in a consistent format, and it is, in my opinion, the most elegant source-based dependency resolving package management system in the GNU/Linux world (of course *BSD's ports system cannot go unmentioned, but it is obviously not available in GNU/Linux).

In the end, Slackware has quirky philosophies -- it keeps the system very simple and puts all of the blame on you, the administrator. With tools like sbopkg and repositories like slackbuilds.org, Slackware is a *much* friendlier distribution than it once was, but its philosophies are unchanged. If you don't see the advantages of source-based package management and/or you do not want to deal with dependency management yourself, perhaps binary-based distributions would be more suitable (or at least dependency-resolving source-based package managers). The lack of dependency resolution is considered a feature of Slackware since you, the system administrator, dictates exactly what you install on the system. Of course this is a half-truth since a full installation of Slackware is completely binary-based (though perhaps fairly generic compared to some other distributions).

Currently I run a 40GB SSD in my Laptop, so no 100+ Gigs, and I don't think that every Slackwareuser has 100+ Gigs. I personally like slim systems, that are tailored to my needs, so I don't see the point in installing 5GB of software to this machine to get rid of dependency checking.

@aocab: +1 for this, but is this manual dependency checking anymore? But of course very helpful.

Sounds like you are talking about pre-built packages. I either find out from the packager, or use ldd on all the binaries and libraries.

First, thanks for the links you mentioned and the time I cost you.

I think I am not fully understanding this.How can I dictate what is installed on my system, when I am supposed to install the whole repository?
But when I make a full installation, will it not build against anything in the repository it can?

I have an 80GB HD with almost 60GB for slackware (minux swap, testing, windows).

I never have problem with dependency except when I attempt to install tovid and dvdauthor. I almost gone crazy installing dependency after dependency. The rest, there are like 2 to 4 average dependency - slackbuilds.org packages.

If you wish to narrow down the installed packages included with the full Slackware installation, you really just need to know what you're doing. This is easiest during installation when you can exclude entire package sets (like kde, e [for emacs], tcl, etc.) and then slim down those that you do wish to install using expert/menu mode. However, you should be able to uninstall entire package sets using slackpkg (for example, `slackpkg remove kde` should, unless I got my syntax wrong, uninstall the kde series of packages). See here for the package set descriptions (and of course note that GNOME is no longer shipped with Slackware). Refining beyond that just requires experience, or picking out the obvious. If you wish to create a truly minimal system then see the various threads on the subject, like this one.
It depends on the application. Usually the configure script tries to automatically determine the dependencies that are installed and build against it if it is present, but this can usually be prevented by passing a "--without-package" or "--disable-package" option, for example. Sometimes building against a dependency may be disabled by default and you would have to add "--enable-package" or "--with-package" -- though usually when you build using the SlackBuilds from slackbuilds.org any optional dependencies will be listed and might just require passing a parameter to the script instead of modifying the ./configure options explicitly. Take the ffmpeg SlackBuild, for example, which takes several arguments to enable or disable a dependency.

I think it is important to note the distinction between packages included by default with Slackware and third-party packages that you add. Slackware is shipped as a full distribution and is meant to be installed completely. HOWEVER, not every package is linked against every other package, and there is a *lot* that you can exclude without trouble. In general, you should install all of the a/ series, most of the ap/ series unless there is something you obviously do not want, all of the d/ series (unless you want to get into trouble later when you try to compile something from source), the k/ series, most (or all) of the l/ series, most of the n/ series, most of the x/ series, and much of the xap/ series (though you can be more selective here). The other series might include software that you want, but are basically optional.

With experience you'll know if you need something or not and unless you are trying to create a truly minimal system, it isn't too much trouble to pare down a Slackware install.

Now, again with that distinction -- I was definitely referring to third-party applications that you install (usually compiled from source) when I was talking about your ability to decide what gets installed and what doesn't. I currently have 147 packages installed that did not ship with Slackware. 127 of those are from slackbuilds.org (you should note that I work a bit with audio, which definitely adds a lot of dependencies. For completeness' sake, 2 are from Alien Bob, 1 is sbopkg, and the rest [17] I compiled myself). There are optional dependencies that I explicitly did not install because either I did not like the dependency or I would have no use for it. The only way to include/exclude these dependencies at will is to use source-based package management (dependency-resolving source-based package managers have the ability to exclude dependencies as well, but require an extra configuration step...outside of audio/video dependencies, long dependency trees are relatively rare and thus handling them manually doesn't really take much extra time, especially with sbopkg's queues. If it is still too much work for you, however, I would suggest Gentoo or maybe Arch as possible alternative distributions if you still want a source-based distro). I hope you can see the benefit of slackbuilds.org here -- dependencies for every package are clearly listed, and with sbopkg you can create a queue with the proper build order for your desired application and any dependencies with relative ease. This also forces you to read about what dependencies are being installed instead of mindlessly installing anything that is supposedly needed for an application -- but since any good dependency-resolving package manager lets you review the to-be-installed packages before doing anything, this is really a moot point.

I think I've rambled for long enough. Managing a Slackware system is not as difficult as it may seem after this rather lengthy thread (thanks in no small part to my rambling), but it does have certain philosophical differences when compared to other distributions that you must be on board with if you are to be a happy Slacker. If you don't agree with those differences...then there are always other distros out there that may suit your needs/wants better.

Thank you for your really good explanations, I think I understand that now and will poke around with it to see if this will work for me.