On Fri, 2007-02-23 at 09:42 -0600, Mike McCarty wrote: > chris@xxxxxxxxxxxx wrote: > >> Date: Thu, 22 Feb 2007 18:39:22 -0500 > >> From: Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> > > > > > >> chris@xxxxxxxxxxxx writes: > >> > >>> Lesson learned: *NEVER* kill a yum update, no matter how long it takes. > >> > >> > >> Come and join the party we're having in another thread. > > > > > > Seen it. It prompted me to write. > > Perhaps yum should trap some signals, and request confirmation > before dieing. or die w/o clobbering the database. At most, one package being out of sync in the database and filesystem should happen - but database should not be corrupted - and if the plug is pulled, it should be able to recover losing at most one transaction. btw - another point of failure is the gconf database. I found this out the hard way. If a ram chip goes bad with occasional failures and there are a lot of gnome updates - you are screwed. You can replace the ram chip, use rpm --verify to find and fix any mis-installed files, but your desktop environment is royally screwed. There needs to be a way or utility to repair a damaged gconf database (preferably a pro-active utility that detects a problem and either fixes it or offers to) other than re-install. I sure as hell couldn't figure out how to, and it ends up being no different at all than a FUBAR windows registry (IE clicking a link in evolution does not work becsause no default browser is defined but gconf-config crashed if you try to set one in preferences). Well actually, there is a difference - windows makes periodic backups of its registry (and face it, gconf is a registry - they just don't call it that to avoid the backlash) AND there _are_ user friendly repair utilities.
