Bug 13735

Summary: RPM 4.0 bug/annoyance
Product: [Retired] Red Hat Raw Hide Reporter: fruitbat
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 1.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-07-11 17:41:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description fruitbat 2000-07-11 17:13:14 UTC
I recently upgraded my rpm package from 3.0-6.0 to 4.0-0.45, acquired
from rpmfind.net, and had it appear to eat my db.  After struggling
with it for a while, I learned that the problem was that 3.0 hadn't
erased the old db files when it upgraded itself (wisely, I think), but
4.0 was seeing the continued presence of /var/lib/rpm/*.rpm as an
indication that the db hadn't yet been updated, even after I ran
--rebuilddb.  The solution was to move /var/lib/rpm/*.rpm somewhere
else, after which 4.0 was happy as a clam.

The problem is that it's not obvious what to do in a situation like
that, and although I was able to figure it out, and am not an RPM
power-user by any means, people who have less time and experience are
going to get hosed as their new RPM just -stops working-.  At the very
least, the stuff that goes into /usr/doc/rpm-4.0 might say something
to the effect that after running --rebuilddb you'll need to dispose of
the *.rpm files before 4.0 will be happy.  A hint in the error message
that comes up when rpm 4.0 first advises running --rebuilddb would
also be well-placed.  Moving the .rpm files to .rpm.old would fix the
whole thing silently, and consistently with the standard way that RPM
deals with outdated but potentially useful data files.  A more clever
solution might involve having 4.0 compare mod times between the db3
files and the older ones and see if --rebuilddb has already been run,
but that sort of thing might be trouble so I can see you all not
wanting to get into it.  In any event, a blatant hint for the
otherwise clueful but rpm-unaware would save a lot of trouble for
people, I think.

(The reason this came up for me at all is because a client stalled
completely on an upgrade project after putting 4.0 on his system, and
couldn't figure out what happened -- this is a person who knows
systems programming very well, and is no idiot around the machines
normally, which is why I got to thinking that a word to the wise would
be useful.)

Lastly, thank you all for a generally tremendous job on the package
management stuff -- rpm is near the top of my (very short!) list of 
software that doesn't suck.

Comment 1 Jeff Johnson 2000-07-11 17:41:57 UTC
Yup. Your analysis and suggestions are definitely appreciated.

Comment 2 Jeff Johnson 2000-07-19 16:34:27 UTC
These problems should be fixed in rpm-4.0-0.56 packages  You can get the latest
copy of rpm-4.0
from
	ftp://ftp.rpm.org/pub/rpm/test.