Bug 495796 - anaconda upgrade needlessly reinstalls same version of RPMs
anaconda upgrade needlessly reinstalls same version of RPMs
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
i686 Linux
low Severity low
: rc
: ---
Assigned To: Radek Vykydal
Alexander Todorov
Depends On:
  Show dependency treegraph
Reported: 2009-04-14 16:05 EDT by Greg Bailey
Modified: 2014-01-21 01:12 EST (History)
6 users (show)

See Also:
Fixed In Version: anaconda
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-30 04:02:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda install.log after initial 5.3 install (13.93 KB, text/plain)
2009-04-14 16:05 EDT, Greg Bailey
no flags Details
anaconda upgrade.log after choosing "Upgrade system" (391 bytes, text/plain)
2009-04-14 16:06 EDT, Greg Bailey
no flags Details
/tmp/anaconda.log when performing "Upgrade system" (26.33 KB, text/plain)
2009-04-14 16:06 EDT, Greg Bailey
no flags Details
Proposed patch to yuminstall.py (1.35 KB, patch)
2009-08-18 19:17 EDT, Greg Bailey
no flags Details | Diff

  None (edit)
Description Greg Bailey 2009-04-14 16:05:04 EDT
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- (Red Hat Enterprise Linux 5.3 install DVD)

How reproducible:


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
Comment 1 Greg Bailey 2009-04-14 16:06:04 EDT
Created attachment 339570 [details]
anaconda upgrade.log after choosing "Upgrade system"
Comment 2 Greg Bailey 2009-04-14 16:06:46 EDT
Created attachment 339571 [details]
/tmp/anaconda.log when performing "Upgrade system"
Comment 3 Chris Lumens 2009-08-14 11:55:52 EDT
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.
Comment 4 seth vidal 2009-08-14 12:08:46 EDT
What ver of yum is on the 5.3 update disks?
Comment 5 Greg Bailey 2009-08-14 15:12:25 EDT
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'
Comment 6 Greg Bailey 2009-08-14 17:51:39 EDT
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
Comment 7 Greg Bailey 2009-08-18 19:17:24 EDT
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.
Comment 8 James Antill 2009-08-18 19:55:25 EDT
 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@redhat.com>
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).
Comment 9 Joel Andres Granados 2009-08-19 06:46:29 EDT
...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.
Comment 11 Chris Lumens 2009-09-23 11:29:45 EDT
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.
Comment 12 RHEL Product and Program Management 2009-09-25 13:43:43 EDT
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
Comment 14 Radek Vykydal 2009-12-01 05:42:09 EST
Thanks for the patch (comment #7) Greg. It will appear in version of anaconda.
Comment 16 Alexander Todorov 2009-12-14 11:58:29 EST
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
Comment 18 errata-xmlrpc 2010-03-30 04:02:56 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.