Bug 13735 - RPM 4.0 bug/annoyance
Summary: RPM 4.0 bug/annoyance
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm
Version: 1.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-11 17:13 UTC by fruitbat
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-07-11 17:41:58 UTC
Embargoed:


Attachments (Terms of Use)

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.


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