This is very rough-and-ready but it seems to work enough to be useful. The idea is you want to package something for current. This script will check for unmet subdependencies, based on the existing dependencies in Salix stable. Obviously it might not work if those have changed - one example may be the move from gnome to maté.
In general, it doesn't cope well with situations where something is packaged in Slackware, but Salix has its own version. This is a major deficiency I hope to address soon.
One annoyance is the "package" cxxlibs|gcc-g++ - that is, either cxxlibs OR gcc-g++. I don't know if it's the only one like that, but basically, please ignore it or any others.
The script assumes you have run pkgtxt2db for both Salix and Slack current and 13.37 in the directory you call it from first. It also doesn't include 64-bit repos. The output could be tidier. I'll get round to it soon
It's available here:
http://people.salixos.org/mimosa/scripts/pkgdepcheck.py
Build-time deps are not covered, unless they should (exceptionally) appear in the dependency info in the repos.
EDIT
And here is a wrapper to make sure the package data is not only present but fresh. That may take a while (four repos, after all - eight with 64-bit):
http://people.salixos.org/mimosa/scripts/pkgdepcheck.sh
This assumes the main script is somewhere on your $PATH.
EDIT
Fixed the alternative|dependency problem. Actually it now requires *both* rather than either/or, but since the deps are listed just above the missing deps, that isn't a problem in practice (just check the other option on the next iteration).
pkgdepcheck.py - script to find deps of a new package
Re: pkgdepcheck.py - script to find deps of a new package
Related: How to check & install missing deps (by Shador) http://salixos.org/forum/viewtopic.php?f=30&t=1377
Help to make Slackware easier Donate to Salix
Re: pkgdepcheck.py - script to find deps of a new package
Now corrected to cope better with cases where Salix has its own version of a Slackware package.
If it did in the previous version, then it probably will again: so even if the package is present in Slackware current, it isn't counted as meeting a dependency.
If it did in the previous version, then it probably will again: so even if the package is present in Slackware current, it isn't counted as meeting a dependency.