Bug 13735 - RPM 4.0 bug/annoyance
RPM 4.0 bug/annoyance
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm (Show other bugs)
1.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-07-11 13:13 EDT by fruitbat
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-11 13:41:58 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 fruitbat 2000-07-11 13:13:14 EDT
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 13:41:57 EDT
Yup. Your analysis and suggestions are definitely appreciated.
Comment 2 Jeff Johnson 2000-07-19 12:34:27 EDT
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.

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