> > > 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
