Bug 74196 - upgrade.log lies about non-upgraded packages
upgrade.log lies about non-upgraded packages
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
8.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-17 13:04 EDT by Chris Ricker
Modified: 2007-04-18 12:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-09-30 15:49:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Ricker 2002-09-17 13:04:33 EDT
I did an upgrade from 7.3 to 8.  The upgrade.log provides a list of everything
upgraded, and then it provides a list of available but non-upgraded packages:

The following packages were available in this version but NOT upgraded:
gdbm-1.8.0-18.i386.rpm
bzip2-libs-1.0.2-5.i386.rpm
basesystem-8.0-1.noarch.rpm
zlib-1.1.4-4.i386.rpm
libtermcap-2.0.8-31.i386.rpm
sh-utils-2.0.12-3.i386.rpm
mouseconfig-4.26-1.i386.rpm
usermode-1.63-1.i386.rpm
bash-2.05b-5.i386.rpm
setup-2.5.20-1.noarch.rpm
<snip ; ~150 packages listed as not upgraded>

The list of non-upgraded packages is completely wrong.  Every single one of them
that I've checked so far (~15) actually were upgraded.  For example:

[kaboom@hanuman export]$ rpm -q gdbm bzip2-libs basesystem zlib libtermcap
sh-utils mouseconfig usermode bash setup
gdbm-1.8.0-18
bzip2-libs-1.0.2-5
basesystem-8.0-1
zlib-1.1.4-4
libtermcap-2.0.8-31
sh-utils-2.0.12-3
mouseconfig-4.26-1
usermode-1.63-1
bash-2.05b-5
setup-2.5.20-1
[kaboom@hanuman export]$ 

All these upgraded packages don't have any Upgrading foo entry earlier in the
log like they should (which, presumably, is the logic which got them on the
available-but-not-upgraded list)
Comment 1 Jeremy Katz 2002-09-20 15:19:18 EDT
I can't reproduce this here -- are you sure the machine was running 7.3 before?
 If you check the install date on the packages that it says weren't upgraded
(say basesystem) and compare it to one of the packages that was upgraded, what
do you see?
Comment 2 Chris Ricker 2002-09-20 16:15:51 EDT
I'm absolutely positive it was 7.3.  The only thing on it which I'd upgraded to
newer-than-7.3 was Jakub's gcc3 packages (which coexisted with the RHL 7.3 gcc
packages) and a custom build of postfix.  Everything else was stock 7.3, 7.3
errata, or stuff RH doesn't ship.

The dates definitely show the packages upgrade.log claims weren't upgraded as
having been upgraded.  For example:

[kaboom@hanuman oracle-files]$ rpm -q
--queryformat="%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm Installed
%{INSTALLTIME}\n" firstboot basesystem bash gcc
firstboot-1.0.1-10.noarch.rpm Installed 1032055804
basesystem-8.0-1.noarch.rpm Installed 1032048351
bash-2.05b-5.i386.rpm Installed 1032048431
gcc-3.2-7.i386.rpm Installed 1032054851
[kaboom@hanuman oracle-files]$ 

All four were upgraded (or newly installed, in firstboot's case).  basesystem
and bash were listed in upgrade.log as not being upgraded, though....
Comment 3 Jeremy Katz 2002-10-25 16:41:07 EDT
This has not been reproduced in any upgrade I've done or any of the automated
upgrade tests that we ran during the release cycle.  The code is also very
clearly correct in that the selected attribute of the package is used to
determine whether it should be added to the rpm transaction set and if it's not
selected, then it's printed out at the end.
Comment 4 Michael Fulbright 2002-12-20 12:38:25 EST
Time tracking values updated

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