Red Hat Bugzilla – Bug 495796
anaconda upgrade needlessly reinstalls same version of RPMs
Last modified: 2014-01-21 01:12:42 EST
Created attachment 339569 [details]
anaconda install.log after initial 5.3 install
Description of problem:
When performing a system upgrade using anaconda, several packages are observed to be upgraded, even though the required version is already installed on the system.
Version-Release number of selected component (if applicable):
anaconda-184.108.40.206-1 (Red Hat Enterprise Linux 5.3 install DVD)
Steps to Reproduce:
1. Install minimal Red Hat Enterprise Linux 5.3 system
2. Downgrade an installed RPM: rpm -Uvh libpng-1.2.10-7.i386.rpm --oldpackage
3. Reboot using the 5.3 installation media, and choose "Upgrade system"
4. Observe that 8 additional packages (not counting libpng) are "upgraded", even though the version of each package being upgraded is already installed
9 packages were upgraded (libgcc, setup, filesystem, basesystem, tzdata, glibc-common, glibc, zlib, libpng)
1 package should be upgraded (libpng, in the example above)
install.log, upgrade.log, and anaconda.log will be attached
Created attachment 339570 [details]
anaconda upgrade.log after choosing "Upgrade system"
Created attachment 339571 [details]
/tmp/anaconda.log when performing "Upgrade system"
anaconda's largely just using yum (which in turn uses rpm) for a lot of this logic, so I'm reassigning. I don't see how anaconda could be doing something wrong here.
What ver of yum is on the 5.3 update disks?
On the DVD image:
Within the stage2.img file:
# grep ^__version__ /stage2/usr/lib/python2.4/site-packages/yum/__init__.py
__version__ = '3.2.19'
Reproduced with Red Hat Enterprise Linux 5.4 beta, which appears to have yum 3.2.22:
1. I installed minimal RHEL 5.4 beta system (unchecking all the software groups).
2. I downgraded libpng to the version on the 5.3 install media (using "--oldpackage")
3. I booted off of the 5.4 beta DVD, and chose to upgrade the existing system.
warning: libgcc-4.1.2-46.el5: Header V3 DSA signature: NOKEY, key ID 897da07a
warning: setup-2.5.58-7.el5: Header V3 DSA signature: NOKEY, key ID 37017186
Created attachment 357860 [details]
Proposed patch to yuminstall.py
Not sure if this is really an anaconda bug or a yum one.
I tested the attached patch with both an upgrade (as described in the "Steps to Reproduce"), and with a fresh installation, with no apparently side effects.
Apparently, dependencies pulled in by resolveDeps()in yuminstall are never removed even if the same NAEVR is already installed on the system.
The above patch is def. an anaconda thing, as tsInfo.install isn't meant to be "clever" and check/remove dups. etc.
Although looking at upstream anaconda I can't see anything like the code you've patched. Doing a quick search it appears that the upstream change to fix this was:
Author: Jeremy Katz <firstname.lastname@example.org>
Date: Mon Mar 5 19:28:55 2007 +0000
...which just removes the entire tsCheck function.
...at this stage of 5.4 Greg's patch is probably safer (but I'm not an anaconda developer).
...at this stage of 5.4 Greg's patch is probably safer...
Be that as it may, I would feel much better punting this to 5.5.
The patch in comment #7 looks reasonable to me, though we would have to put package selection/installation through a pretty heavy set of testing afterwards.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Thanks for the patch (comment #7) Greg. It will appear in version 220.127.116.11 of anaconda.
Verified with RHEL5.5-Server-20091213.nightly. Installing an older version of libpng and upgrading with the same distro leads to upgrade.log which has only
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.