yum appears to fail to complete updates if interrupted

[Rodd Clarkson]

On Fri, 2006-08-11 at 10:38 -0400, Horst H. von Brand wrote:
> Gerry Tool <gstool at earthlink.net> wrote:
> > I was performing a yum update in FC5 when the system froze.  On
> > reboot, I executed yum update again and it updated a partial list of
> > the packages that were listed in the first attempt.  However, one of
> > the packages in the original list, but not the second list was
> > firefox, updating to 1.5.0.6.  After the update, my firefox is still
> > at 1.5.0.4.  I have tried several things to get it to update, all
> > unsuccessfully, including yum clean all followed by another update
> > attempt, and downloading the package and using rpm.  That fails due to
> > dependencies which apparently were also in the interrupted update.
> 
> I've had to kill -KILL (no reaction to -HUP and -TERM) yum for various
> reasons, and sometimes it gets messed up in that it claims there are /no/
> updates available (when there clearly are lots of them). Manually deleting
> the files in the local staging areas clears this up when a "yum clean all"
> doesn't:
> 
>   primary.xml.gz primary.xml.gz.sqlite cachecookie repomd.xml
> 
> I'm quite sure this is way overkill, but it works...

Hmmm, yum has quite a lot to do and it can often take some time.  As a
result, it isn't unheard of for a crash (or similar) while yum is doing
it's work.

I can't help but wonder if yum doesn't need some sort of auditing that
would allow yum to recover cleanly from these sorts of situations.

Yum seems to follow a clean line of events.

1. Download information about updates
2. Download update rpms

(at this point a failure in yum isn't likely to cause any issues,
restart yum and it should pick up where it left off.  The only thing I
have seen is that yum doesn't realize that the package currently being
downloaded isn't all there and as a result it fails.  Maybe it needs to
check the shasum of packages that are already cached to see if they are
complete.)

3. Figure out the best order to install updates
4. Install updates
5. Remove older packages
6. Ta Da.

I know this is a little vague, but if this rough view of how it works is
close enough, then a list of things that need to be done during the
critical install/remove stage could be made and then verified as they
are completed.  By doing this, yum could realize that it failed to
complete an update last time it was run and attempt to resume at the
point when it failed.

Does this sound like something that should be BZ'ed as a enhancement?

Or maybe I'm on crack ;-]



R..

-- 
"It's a fine line between denial and faith.
 It's much better on my side"