[arch-general] lddd from devtools rewritten
ino-news at spotteswoode.dnsalias.org
Tue Jul 28 10:16:22 EDT 2009
I rewrote lddd from extra/devtools. The intent was to make it faster
and remove false positives, as well as support for ignoring certain
files completely, filtering the list of missing libs to handle optional
dependencies, take /etc/ld.so.conf into account and in general make it
more usable. NB: uses bash-4 features.
Here's the help screen:
$ lddd-c.sh -h
Use lddd-c.sh [options] [paths]
Default-paths: $PATH, /lib:/usr/lib:/opt/qt/lib:/opt/kde/lib:/usr/lib/libfakeroot:/opt/NX/lib:/usr/local/lib:/usr/local/libexec
-d <item>: do not check glob <item>, can be given multiple times.
-l <item>: ignore missing library glob <item>, multiple times.
-L: do not use LD_LIBRARY_PATH running ldd(1).
-v: be more and more chatty.
-D <glob>: trigger tracing on meeting <glob>, debugging aid.
$LDDD_LIB_IGNORE: globs of missing lib-names to ignore.
$LDDD_DONT_CHECK: globs of file names to completely ignore.
 risks false positives, but finds all broken ELF dependencies.
 space separated list of globs, needs to be quoted to the shell.
NB: A broken ELF file will be reported unless it is ignored ('-d' option
or $LDDD_DONT_CHECK) or _ALL_ of its missing libs are ignored ('-l'
The "new and improved" algorithm goes like this:
1. All files executable by the user or matching the customary *.so
patterns are collected after verifying their ELFness.
2. The file paths are checked to see if their base directories contain
any libraries and these directories are collected into
3. In a third loop, the files from step one are checked by ldd(1)
prefixed with this LD_LIBRARY_PATH to see if any prerequisites are
missing. This step is repeated without the path to check the odd
4. Suspects aquired this way are sent to a co-process to determine the
packages they belong to.
5. Results are collected into files in /tmp/lddd-c.sh-$UID and
a summary listed to stdout. This makes it easy to use in cron-jobs.
Detail is controlled by the number of '-v' options.
Step four was intended to speed up the process, but as it turns out it
doesn't help all that much. The pacman call is indeed expensive and can
be done in parallel, but it obviously competes for disk access.
Therefore the co-process caches the file list of any broken package
expecting to find more broken files in it, but this only helps big
packages with several broken executables.
All in all lddd-c.sh is an improvement over the simpler lddd and the
terribly hacked findbrokenpkgs. As there should be no false
positives, it should report b0rked packages after botched or incomplete
updates in a reliable way.
Valuable testing was done by Allan McRae and AttilaH. Some nasty bugs
would still stink the code without their patience.
More information about the arch-general