see the two packages queried below (package descriptoins elided for brevity): [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: porky.devel.redhat.com Group : Development/Tools Source RPM: doxygen-1.2.1-1.src.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 /system/software/rpm/contrib/doxygen-1.2.3-1.i386.rpm 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: localhost.localdomain Group : Development/Tools Source RPM: doxygen-1.2.3-1.src.rpm Size : 3869083 License: GPL Packager : Dimitri Papadopoulos <dpo> 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.
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.
The epoch is the cause of the problem. I disagree that the error message is confusing, as epoch is (and always has been) part of the algorithm to decide which package is "newer". I agree that epoch's are confusing (but necessary) however.
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 simple.
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 the header, the value is not display using "rpm -qip" because the majority of packages do not have an epoch.
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. --jh--
*** Bug 202066 has been marked as a duplicate of this bug. ***