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-11.1.2.168-1 (Red Hat Enterprise Linux 5.3 install DVD) How reproducible: Always 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 Actual results: 9 packages were upgraded (libgcc, setup, filesystem, basesystem, tzdata, glibc-common, glibc, zlib, libpng) Expected results: 1 package should be upgraded (libpng, in the example above) Additional info: 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: /rhel53/Server/yum-3.2.19-18.el5.noarch.rpm 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. /root/upgrade.log shows: Upgrading libgcc-4.1.2-46.el5.i386 warning: libgcc-4.1.2-46.el5: Header V3 DSA signature: NOKEY, key ID 897da07a Upgrading setup-2.5.58-7.el5.noarch warning: setup-2.5.58-7.el5: Header V3 DSA signature: NOKEY, key ID 37017186 Upgrading filesystem-2.4.0-2.i386 Upgrading basesystem-8.0-5.1.1.noarch Upgrading tzdata-2009i-2.el5.noarch Upgrading glibc-common-2.5-38.i386 Upgrading glibc-2.5-38.i686 Upgrading zlib-1.2.3-3.i386 Upgrading 2:libpng-1.2.10-7.1.el5_3.2.i386
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: commit 0ab9699a5a224c8bd2f92be9f453abf88bee558c Author: Jeremy Katz <katzj> 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 release.
Thanks for the patch (comment #7) Greg. It will appear in version 11.1.2.198 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 Upgrading 2:libpng-1.2.10-7.1.el5_3.2.x86_64
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. http://rhn.redhat.com/errata/RHBA-2010-0194.html