> > > So they are not really the same thing at all.I'm not saying they're
> > > the same, I'm saying it looks like @preserved-rebuild does a subset
> > > of the things revdep-rebuild does.  Why run @preserved-rebuild
> > > followed by revdep-rebuild if the end result is the same as running
> > > revdep-rebuild?  I'm sure I'm missing something here but I don't
> > > know what it is.
>
> OK, I see what you mean.
>
> I'm a pessimistic sysadmin who's written a lot of code. I know bug
> factories when I see one :-)
>
> @preserved-rebuild is an excellent idea, but I haven't seen anything
> yet to convince me that it is bug-free enough yet to the point where I
> can drop revdep-rebuild entirely. So I still want the safety net of
> running revdep-rebuild occasionally just in case there's something
> @preserved-rebuild missed.
>
> It's also a good way to find bugs in @preserved-rebuild

Got it.  So @preserved-rebuild is meant to be a replacement for revdep-rebuild but we aren't sure it's completely ready yet.  In that case, I think I'm ready to switch.

BTW, what should I do about this:

# revdep-rebuild -p
 * Configuring search environment for revdep-rebuild

 * Checking reverse dependencies
 * Packages containing binaries and libraries broken by a package update
 * will be emerged.

 * Collecting system binaries and libraries
 * Found existing 1_files.rr
 * Collecting complete LD_LIBRARY_PATH
 * Found existing 2_ldpath.rr.
 * Checking dynamic linking consistency
 * Found existing 3_broken.rr.
 * Assigning files to packages
 *  !!! /usr/lib64/libsvn_ra_neon-1.so.0.0.0 not owned by any package is broken !!!
 *   /usr/lib64/libsvn_ra_neon-1.so.0.0.0 -> (none)
 *  !!! /usr/lib64/libwebkitgtk-1.0.so.0.11.2 not owned by any package is broken !!!
 *   /usr/lib64/libwebkitgtk-1.0.so.0.11.2 -> (none)
 * Generated new 4_raw.rr and 4_owners.rr
 * Found some broken files, but none of them were associated with known packages
 * Unable to proceed with automatic repairs.
 * The broken files are listed in 4_owners.rr

- Grant