Bug 20264 - rpm wrong about which package is newer
Summary: rpm wrong about which package is newer
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2000-11-03 00:30 UTC by j. alan eldridge
Modified: 2007-04-18 16:29 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-12-22 15:58:05 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description j. alan eldridge 2000-11-03 00:30:22 UTC
see the two packages queried below (package descriptoins elided for
[root@wozzle up2date]# rpm -qi doxygen
Name        : doxygen                      Relocations: /usr 
Version     : 1.2.1                             Vendor: Red Hat, Inc.
Release     : 1                             Build Date: Sat 19 Aug 2000
11:44:15 AM EDT
Install date: Thu 02 Nov 2000 07:23:12 PM EST      Build Host:
Group       : Development/Tools             Source RPM:
Size        : 3461244                          License: GPL
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.stack.nl/~dimitri/doxygen/index.html
Summary     : A documentation system for C and C++.

[root@wozzle up2date]# rpm -qpi
Name        : doxygen                      Relocations: /usr 
Version     : 1.2.3                             Vendor: (none)
Release     : 1                             Build Date: Mon 30 Oct 2000
07:17:52 PM EST
Install date: (not installed)               Build Host:
Group       : Development/Tools             Source RPM:
Size        : 3869083                          License: GPL
Packager    : Dimitri Papadopoulos <dpo@club-internet.fr>
URL         : http://www.stack.nl/~dimitri/doxygen/
Summary     : A documentation system for C and C++.

rpm insists that doxygen-1.2.1-1 is newer than doxygen-1.2.3-1, despite the
version numbers *and* build dates to the contrary.

Comment 1 Michael Schwendt 2000-11-12 19:06:16 UTC
The package shipped by Red Hat has a "hidden" serial number set:

  rpm -q --qf "%{SERIAL}\n" package-name 
  rpm -qp --qf "%{SERIAL}\n"  file-name

Upgrade the file with rpm -Uvh filen-ame --force. ;-)

I also find the error message highly confusing. RPM ought to make clear why it
rejects installation of a package.

Comment 2 Jeff Johnson 2000-12-22 15:35:18 UTC
The epoch is the cause of the problem.

I disagree that the error message is confusing, as epoch is (and always has
part of the algorithm to decide which package is "newer". I agree that epoch's
confusing (but necessary) however.

Comment 3 j. alan eldridge 2000-12-22 15:58:01 UTC
i have to disagree with your comment (which, btw, provided really no substantive
information other than that you disagree).

given  the default information that is displayed with rpm -qpi (as above),
please elucidate what part of "package with lower version number built on an
earlier date is the newer pacakge" is not confusing. yes, i can go to max rpm
and find out about the epoch (which 8I* always thought meant the beginning of
unix time, 1/1/1970) as rpm defines as uses it, but the point is that i *should*
*not* *have* *to* *do* *that*. to me, a higher version number combined with a
later build date means "newer". if rpm is going to insist on not doing what i
wnat for a reason that is counter to all intuition and to all default
information displayed about a package, it ought to tell me why. it's that

Comment 4 Jeff Johnson 2000-12-30 18:49:52 UTC
You are misinformed about rpm's concept of "newer", as build time is not used to
decide whether a package should be upgraded. The epoch, formerly called serial
number, of a package can be displayed with a query, just like any other tag in
header, the value is not display using "rpm -qip" because the majority of
do not have an epoch.

Comment 5 Joe Harrington 2001-01-25 18:22:50 UTC
I guess I agree with alane.  Intuition beats documentation.  The places where it
doesn't are often places where even experienced system managers spend huge
amounts of time chasing down dead ends when the real problem is hidden.  Since
"epoch" (necessarily) outranks the version numbers, rpm can and should at least
state that, since it *doesn't* state that in the package info.  The concept is
not in the lexicon of most people using RPM, unless they also build packages
with it.  We're not talking about a change in behavior here, just a change in
the error message.  I hope you'll consider it for the next version.  It should
be easy to do.


Comment 6 Mike McCune 2006-09-28 23:42:53 UTC
*** Bug 202066 has been marked as a duplicate of this bug. ***

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