Page 1 of 1

pkgdepcheck.py - script to find deps of a new package

Posted: 26. Aug 2012, 19:31
by mimosa
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).

Re: pkgdepcheck.py - script to find deps of a new package

Posted: 27. Aug 2012, 14:16
by zAchAry
Related: How to check & install missing deps (by Shador) http://salixos.org/forum/viewtopic.php?f=30&t=1377

Re: pkgdepcheck.py - script to find deps of a new package

Posted: 27. Aug 2012, 22:32
by mimosa
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.