Catacombs glad you are back to slack but 12.2 was the first time slackpkg was actually part of installed system. . I tried it on something I forget and it found the dependencey. On some custom builds I did it at least gave me the read out to fix the dependency. as far as using autogen or configure slackpkg can be used to build that program and the read out is the same but when your done you have a nice package.to up grade if you have to.
The cool thing is your the one in control over the building. and I find a lot of packages built will load and work on my system but you will also get a read out that the dependency for actually building that program are not met. but you can run it.

Yes, I did note with interest that they are including slackpkg as an official part of the distribution now. I may try it out again at some point, if I need an application with a large list of dependencies. However, Slackware has come a long way now with the libraries it includes, and I'm yet to struggle with dependencies so far. With version 12.0, I had serious troubles getting wxGTK, wxPython, pyGTK updated to versions that I needed for many applications. Now, it's almost all there.

I'm no developer, but I'm sure Slackware's tools could make an excellent basis for a dependency-aware package manager. All you would need is a simple script that says:

If package x.tgz does not exist, then installpkg x.tgz
If package x.tgz exists in an earlier version, then upgradepkg x.tgz
If package x.tgz exists, then do nothing.

I guess things get more complicated when you consider that there may be two applications that depend on different versions of the same library and all the other issues that such programs have. However, I'm surprised that I've never had any success with automated Slackware package-management. Still, perhaps I'm wrong and slackpkg is now ready.