This is an incomplete, but functional script that I hope will one day replace revdep-rebuild. It uses scanelf instead of ldd, and outputs portage-compatible package lists to stdout, so you can pipe it to any package manager. It's also quite a bit faster than revdep-rebuild, and doesn't use any tempfiles.
Created attachment 123953 [details] scanelf-packagecheck-0.01 Please let me know if you think I'm headed in the right direction or going the wrong way.
A few code comments wouldn't hurt ... At least a simple description for each function.
Created attachment 123972 [details, diff] scanelf-packagecheck.addcomments-argchecking.patch 1) added comments 2) --quiet works 3) enforces required arguments to commandline parameters 4) hid -L option until I have time to implement it.
So far it looks fine to me and I don't think that you are headed in the wrong direction. pvarner@beldin ~/src/revdep-rebuild $ scanelf-rebuild.sh -bl Dynamic linking is consistent No dependencies missing from .la files pvarner@beldin ~/src/revdep-rebuild $ scanelf-rebuild.sh -b -l ./scanelf-rebuild.sh: line 146: shift: -1: shift count out of range Dynamic linking is consistent
i'd use `type -P` rather than `hash` shouldnt these checks: [[ avoid_utils != *..... actually be: [[ ${avoid_utils} != *.....
Created attachment 124023 [details, diff] scanelf-packagecheck.patch Thanks! Fixed the bugs mentioned in comment #4 and comment #5. For the record if you want to use getopts in a function, make all of getopts' variables local or manually reset them, or you will not be able to call the function twice.
(In reply to comment #5) > i'd use `type -P` rather than `hash` Meant to ask why... Why?
`type` is in POSIX (although -P is not), so you tend to see `type` or `which` in scripts ... honestly, i dont think ive ever seen `hash` some other notes: - why reimplement die/warn funcs rather than using /etc/init.d/functions.sh ? - you can indent cat by doing (make sure you tab indent everything): cat <<-EOF foo EOF - might have to get some feedback for BSD users about `find` usage and such ...
(In reply to comment #8) > `type` is in POSIX (although -P is not), so you tend to see `type` or `which` > in scripts ... honestly, i dont think ive ever seen `hash` hash is POSIX and I prefer its syntax and output ever-so-slightly more than type. I don't think 'which' is POSIX. > some other notes: > - why reimplement die/warn funcs rather than using /etc/init.d/functions.sh? To be honest, I didn't use /etc/init.d/functions.sh because I didn't know about it. I'm still having doubts about using it because it's a lot of stuff I won't use, and I only need those two functions. > - you can indent cat by doing (make sure you tab indent everything): > cat <<-EOF > foo > EOF I just learned this syntax recently, and I like it a lot, but I don't want to use it for print_usage() because it's easier to eyeball the output for wrapping at column 80 without it. > - might have to get some feedback for BSD users about `find` usage and such There are two ways I'm using find that aren't POSIX compliant. One is -print0, and that is entirely superfluous, so I'll remove it. (If there are ever any spaces in filenames in vdb I'm sure this isn't the only program that'll break.) The other is multiple /path/ arguments, about which POSIX is not too clear. I'm not sure how to avoid multiple path arguments except an expensive loop, and I'm pretty sure all Gentoo finds including the BSD ones will support multiple path args. Speaking of POSIX, I know the script uses a lot of bashisms. Every time I go to sh-ize it I realize I should just write it in python. Unfortunately I suck at python, and am pretty good at bash, so I get stuck. :( Hopefully I'll remedy this at some point.
`which` is not POSIX the point of exposing /etc/init.d/functions.sh to users is so that Gentoo scripts have a semi-standard output format ... you inherit it and use `eerror` and it looks the same as everyone else using `eerror`. even if you only use one or two functions, please use it. just because existing utilities have whitespace limitations does not mean future ones should ... we've been making exceptions for `-print0 | xargs -0` because of this and because all the ports we support includes this functionality writing the script in pure bash is OK so long as you use #!/bin/bash at the top so dont worry about trying to re-implement in #!/bin/sh ... especially considering i doubt you'll get a noticeable speedup: the disk I/O here will take much much longer
I'm having trouble replicating a relatively recent addition to revdep-rebuild functionality with scanelf. For example: $ ldd /opt/sun-jdk-1.4.2.14/jre/lib/i386/libnio.so /opt/sun-jdk-1.4.2.14/jre/lib/i386/libnio.so: /usr/lib/libnet.so: no version information available (required by /opt/sun-jdk-1.4.2.14/jre/lib/i386/libnio.so) linux-gate.so.1 => (0xb7fe4000) libjava.so => not found libnet.so => /usr/lib/libnet.so (0xb7faf000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7f99000) libc.so.6 => /lib/libc.so.6 (0xb7e78000) /lib/ld-linux.so.2 (0x80000000) How might I get scanelf to tell me there's a problem with /opt/sun-jdk-1.4.2.14/jre/lib/i386/libnio.so, and dev-java/sun-jdk:1.4 should be rebuilt?
that output to me says /usr/lib/libnet.so is broken, not /opt/sun-jdk-1.4.2.14/jre/lib/i386/libnio.so ... can you post those two libraries from your system so i can poke em ?
Created attachment 124181 [details] libnet_libnio.so.tar.bz2 $ tar -tjf libnet_libnio.so.tbz opt/sun-jdk-1.4.2.14/jre/lib/i386/libnio.so usr/lib/libnet.so.1.3.0 Thanks, vapier, poke away. I noted libnet.so was a symlink to libnet.so.1.3.0, so I included that file instead.
On my very broken test system, revdep-rebuild produces: * Checking dynamic linking consistency [ 16% ] * broken /usr/bin/gpg-agent (requires libpth.so.14) [ 16% ] * broken /usr/bin/gpgsm (requires libpth.so.14) [ 22% ] * broken /usr/bin/nautilus (requires libexif.so.10) [ 22% ] * broken /usr/bin/nautilus-connect-server (requires libexif.so.10) [ 22% ] * broken /usr/bin/nautilus-file-management-properties (requires libexif.so.10) [ 92% ] * broken /usr/libexec/battstat-applet-2 (requires libapm.so.1) [ 94% ] * broken /usr/libexec/gnome-screensaver/floaters (requires libexif.so.10) [ 94% ] * broken /usr/libexec/gnome-screensaver/popsquares (requires libexif.so.10) [ 94% ] * broken /usr/libexec/gnome-screensaver/slideshow (requires libexif.so.10) [ 95% ] * broken /usr/libexec/vino-server (requires libXdamage.so.1) [ 100% ] * broken /usr/lib/libgnutls-extra.so.13 (no version information available) * broken /usr/lib/libgnutls-extra.so.13.0.9 (no version information available) scanelf-rebuild produces: # ./scanelf-rebuild.sh -b Dynamic linking is consistent
it's questionable whether re-emerging the package in question would even "fix" the issue. a more interesting question is where did that version information go ?
I'm hoping to get a little more feedback on this package -- where it should head feature-wise, what improvements I can make in terms of usability and speed, and most importantly how I can make better use of scanelf. Any input would be most welcome. :)
Created attachment 133151 [details] scanelf-packagecheck-0.04.bash This one is much more sophisticated than earlier versions -- among other things it masks libs like libjvm.so and counterparts (right now it uses /etc/revdep-rebuild/* for this). It also allows you to specify your package manager and have some control over the output noisiness.
If the qatom bug described in bug #166767 pops up it will break scanelf-packagecheck.
Created attachment 133229 [details, diff] scanelf-packagecheck-0.04-0.05.patch Some bug fixes: - accidentally capitalized "paludis" where I shouldn't've - checks for dependency on portage-utils (q)
Created attachment 135793 [details] scanelf-packagecheck-0.06 This version doesn't use qatom, so isn't susceptible to the blocker bug anymore...
Removed blocker.
(In reply to comment #18) > If the qatom bug described in bug #166767 pops up it will break > scanelf-packagecheck. > That should also no longer be a problem.
revdep-rebuild is being rewritten to utilize scanelf, so this will eventually get resolved as wontfix or obsolete. However, I'm making it block the gentoolkit-0.3.1 Tracker bug, since the logic in the script can be useful as the replacement is being rewritten.
