Jeffrey Smelser:
> there is a rev-rebuild as part of the gentoolkit package. Anytime you
> replace a library such as that.. Theory says, its suppose to provide
you
> with this information... I think it will even recompile things that
need
> to be recompiled.
>
> I have only used it once, and it worked for that.. I just don't recall
what
> it was for...
Hmmmm......It takes a 'qpkg --list gentoolkit' to reveal that
revdep-rebuild is provided in /usr/bin:
files jtosburn # man revdep-rebuild
No manual entry for revdep-rebuild
files jtosburn # revdep-rebuild --help
Usage: /usr/bin/revdep-rebuild [OPTIONS] [--] [EMERGE_OPTIONS]
Broken reverse dependency rebuilder.
-X, --package-names recompile based on package names, not exact
versions
--soname SONAME recompile packages using library with SONAME
instead
of broken library
--soname-regexp SONAME
the same as --soname, but accepts grep-style
regexp
-q, --quiet be less verbose
Calls emerge, all other options are used for it (e. g. -p, --pretend).
If the developers think it's broken, then I wouldn't trust it, and I'm
not sure that it does what I'm looking for, anyway.
So the question remains: how the heck do you know what needs to be
recompiled after any given (particularly security-realted) update? How
many people are still running a mod_ssl that was compiled with a
vulnerable openssl; sure they read the GLSA's and knew to update
openssl, but nothing was said about anything that is statically linked
to it. I don't expect that the devels would ever list every program
possibly affected by a GLSA, but there ought o be a way for admins and
users to figure out what's what on their systems.
-Joel Osburn
--
[EMAIL PROTECTED] mailing list
