gconf (was Re: RPM Database Corruption)

[Michael A Peters]

On Fri, 2007-02-23 at 09:42 -0600, Mike McCarty wrote:
> chris at idlelion.net wrote:
> >> Date: Thu, 22 Feb 2007 18:39:22 -0500
> >> From: Sam Varshavchik <mrsam at courier-mta.com>
> > 
> > 
> >> chris at idlelion.net 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.