Red Hat Bugzilla – Bug 115916
after removing a package yum header info isn't updated
Last modified: 2014-01-21 17:49:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
After removing a package with `rpm -e` or `yum remove` subsequent
operations with yum (install, update, remove, etc) fail during the
"Downloading needed headers" stage. Usually I'm told it could not
locate the header file on the server for the package I just removed.
One time issuing a `yum clean` resolved the problem, but the only sure
way I can find to avoid this problem is to delete the cache folder for
the repository in question.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Uninstall a package
2. try to install, update, or remove a package with yum
Actual Results: Yum fails with an error that it can't find a header
on the server for the package removed in step 1 during the
"Downloading needed headers" stage.
Expected Results: The operation in step 2 should complete
successfully, assuming the package dependencies can truly be resolved
I've been cycling through the various mirrors that the default up2date
sources generates, and this behavior happens no matter which server I
are you sure about that yum version?
2.0.2-20040103 shouldn't exist anywhere.
Is it a specific header or ANY header.
can you capture a traceback from yum and/or yum -d 5 of what happens?
Sorry, should have done copy/paste for version, it's
yum-184.108.40.20640103-1. The missing header is always for the package I
just uninstalled. In the case where I remove multiple packages in one
command, it is the first package listed in the remove operation. I've
run yum -d 5 and am attaching the output.
Created attachment 97721 [details]
output of `yum -d 5 update`
Not wanting to remove the entire cache for the currently configured repository,
I instead issued `rpm -e jfsutils reiserfs-utils mailx logwatch` followed by
`yum clean` and `yum -d 5 update > /tmp/yum.og 2>&1`. The output of the `yum -d
5 update` is the attachment.
so this is odd.
Are you behind a proxy or maybe a transparent proxy?
It seems like you're getting intermittent transfer errors.
I'm not aware of any proxies. I have Time Warner Cable in Austin, Tx,
and haven't had to configure a proxy for anything as long as I've had
it. I should note that yum, apt/synaptic, and up2date (with yum and
apt repos) all worked fine in FC1. Also, up2date with yum repos works
fine in this installation. I haven't seen apt/synaptic for FC2-test1
pop up on fedora.us or freshrpms.net, so I haven't tried that yet.
Also, I can consistently fix the problem by deleting
/var/cache/yum/development (since all the mirrors I've tried so far
write their cache to that common folder). Of course yum then has to
download all the headers.
could you see if you can fix the problem by removing just the
header.info file and not all the headers?
That didn't work the last time I tried it, this time it seems to be
pulling the whole set of sources. I assumed I was also supposed to
issue a yum clean after deleting the header file, but just a plain yum
cleam hasn't been making it pull the whole set of headers before now.
ok, I think what's happening is you're seeing the cache check but it's
not actually downloading anything.
run a yum -d 5 when you next try this. Attach the output to this bug.
Let's see if that's the culprit.
Created attachment 97848 [details]
output from various yum commands
Ok, here's what I did
1 `yum remove vim-X11`
2 `yum -d 5 update 2>&1 | tee /tmp/1-yum_update_after_remove.log`
I encountered the error about trying to retrieve the header file for vim-X11.
So I tried to delete it from the local cache, but it wasn't there!
3 `yum -d 5 clean 2>&1 | tee /tmp/2-yum_clean_after_remove.log`
4 `yum -d 5 update 2>&1 | tee /tmp/3-yum_update_after_clean.log`
At this point I still don't have a header file for vim-X11 to delete, and I
can't run rum update.
There are currently 350 updated package, so I'm going to delete the local cache
so I can get updated.
This is from an unsupported release which nobody should still be
using, so it should probably be closed WONTFIX
closing wontfix, thanks.