Description of problem:
(See Bug #196585)
When yum updates and needs to remove a kernel (due to the installonlyn module),
it both removes and updates other packages in the transaction rather than just
updating. This clobbers configurations badly, and is quite serious. I have given
a detailed description in bug 196585 (as I initially thought it was a shorewall
packaging bug).
Version-Release number of selected component (if applicable):
yum-2.6.1-0.fc5
How reproducible:
Every time
Steps to Reproduce:
1. See Bug #196585 for a recipe to reproduce the bug.
2.
3.
Actual results:
Packages are removed and updated
Expected results:
Packages are updated
Additional info:

I'm happy to, except there is one problem - to reproduce the system state I'll
need to reinstall kernel-smp-2.6.16-1.2111_FC5 and accompanying devel package -
however, these have vanished from the updates server - is there anyway of
getting hold of older updates? I could simply reduce tokeep = 2, but I suspect
the bug will not manifest itself then - can you let me know if there is anywhere
I can pick up the RPMs for 2111 ?

Okay, this is bizarre. So much for my theory of it being something somehow
related to the more explicit install + upgrade paths that installonlyn hits.
Paul -- really, at this point, all I can think is that we're somehow hitting
weirdness in rpmlib. But a quick runthrough doesn't have me see anything.
Thoughts on more debugging avenues?

This is such a severe bug, with the capacity for leaving a system unbootable
(see reports which have been marked as dupes of this one) that I wonder if, in
the event that the issue with rpmlib can't be found, FC6 should ship without
installonlyn activated - that way there won't be any yum "update" transactions
which remove kernels, which seems to be the trigger for the bug. I realize this
is suboptimal, but it's preferable to leaving things as they are. Thoughts?

Michal - I imagine that if you had reverted to an earlier kernel such that the
update transaction involved installing a new kernel and removing an old one, you
would have seen the issue again.
A suggestion: For rawhide, would it be possible to leave old kernels in the
repository (or another repository), so that we can easily check for this
situation arising with the test releases.

> Are you still seeing this with yum 3.0?
I did not see that for a while but every time I tried to recreate
the condition on purpose I failed. It is not so easy to repeat it
and I really cannot tell what was the trigger. yum 3.0 is a few
days old so the question may be a bit premature. :-)
OTOH it was really a long time ago when I was adversely affected by
the issue.

Life is a bit hectic currently, so I'm not currently running a rawhide box.
However, I would caution against the idea that the issue was fixed by yum 3.0,
given that it looked like the problem resided in rpmlibs rather than yum before.

Created attachment 140807[details]
Last 1000 lines of my yum.log
I got hit by this in devel during the past week.
/etc/yum.conf ended up renamed /etc/yum.conf.rpmsave and yum wouldn't run.
I look through my yum.log. Just before it occurred,there was a new version of
rpm loaded. In fact it looks like it started after updating rpm during yum's
run. It continued for a couple of subsequent runs of yum, but after a couple
of days, it stopped occurring. The system has been running for 18 days, so it
wasn't a reboot that occurred.

I found today after an rawhide update and in the same transaction:
....
Removing : texinfo
....
Updating : texinfo
....
There are no config files involved so in this case there are no
adverse consequences.
yum-3.0.1-1 and rpm-libs-4.4.2-35.fc7