Situation improving.  Ben suggested that something like this:

   yum reinstall $( rpm -qa --qf '%{name}\n' )

...would be one way to refresh the on-disk images along with the
corresponding MD5 sums in the RPM database, but some kind of RPM
dependency hell (maybe just in my situation?)  made that all-at-once
approach unworkable so I changed it to a one-at-a-time affair, thus:

   while read p ; do
       echo "########################" BEGIN "${p}" ;
       yum reinstall -y --verbose "${p}"            ;
       echo "#########################" DONE "${p}" ;
   done <       <(rpm -qa --qf '%{name}\n' | sort -u)

...in order to get as many packages as possible reinstalled while not
allowing the b0rken ones to bring everything to a halt; I figured I could
deal with those later.  The downside of this approach is that it appears
that a *lot* of initialization (computing a current package list and
dependency graph, finding a repository, etc) is repeated for each package
instead of it being amortized across the whole set.  The upside is that,
for whatever reason, it appears all packages got reinstalled with no
sign of the dependency problems seen with the all-at-once approach.  (?)

As that loop cranked ponderously along (~4hrs) it all seemed to be
working more or less as hoped except that for every package this message
was shown:

   Warning: scriptlet or other non-fatal errors occurred during transaction.

...with no explanation or other indications of trouble.  Maybe if I had
boosted the verbosity or debug levels an explanation might have been
provided but I was far enough along that I didn't't want to interrupt it.

Now rpm --verify --all reports no MD5 errors except the expected ones
for locally modified config files.  Even with prelink active - Yay!

I'll note one other (trivial) problem - the dbus-devel packages that
are present in both their i386 and x86_64 incarnations seem to fsck up
the verification phase by presenting conflicting MD5 lists for some of
their files.  When I had both packages present the command "rpm --verify
dbus-devel" showed this sort of stuff:

        .
        .
        .
   ..5.....    /usr/share/devhelp/books/dbus/api/structBusData.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusAddressEntry.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusAllocatedSlot.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusArrayLenFixup.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusAtomic.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusAuth.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusAuthClient.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusAuthCommandName.html
   ..5.....    
/usr/share/devhelp/books/dbus/api/structDBusAuthMechanismHandler.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusAuthServer.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusAuthStateData.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusBabysitter.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusCondVarPThread.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusConnection.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusCounter.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusCredentials.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusDataSlot.html
   ..5.....    
/usr/share/devhelp/books/dbus/api/structDBusDataSlotAllocator.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusDataSlotList.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusDirIter.html
   ..5.....    /usr/share/devhelp/books/dbus/api/structDBusError.html
        .
        .
        .

...but now that I've removed the i386 version and reinstalled the x86_64
version all is well.  >-/

_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Reply via email to