Bug 103323

Summary: 'rpm -e xanim' reports no error but does NOT remove the package
Product: [Retired] Red Hat Linux Reporter: Elijah Newren <newren>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED WORKSFORME QA Contact: Mike McLean <mikem>
Severity: high Docs Contact:
Priority: medium    
Version: 9CC: michael
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-12-27 16:13:23 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:
Attachments:
Description Flags
Output from 'rpm -evvvv xanim' none

Description Elijah Newren 2003-08-28 21:01:05 UTC 
Here's what I'm seeing:

  [root@sobaka rpm]# rpm -q xanim
  xanim-full-2.80.1-1
  [root@sobaka rpm]# rpm -e xanim-full
  error: package xanim-full is not installed
  [root@sobaka rpm]# rpm -e xanim
  [root@sobaka rpm]# rpm -q xanim
  xanim-full-2.80.1-1
  [root@sobaka rpm]#

This appears to be a stupid package with name='xanim' and
version='full-2.80.1-1'.  I can verify that a long list of files belonging to
xanim are still installed as well.  Also, in case it is of interest:

  [root@sobaka rpm]# rpm -V xanim
  Unsatisfied dependencies for xanim-full-2.80.1-1: glibc = 2.0.7-29
  S.5....T   /usr/X11R6/bin/xanim

I also noticed that the rpm -e command creates the files
/var/lib/rpm/__db.00[1-3] for some reason (which reminds me of the rpm locks
experienced a lot under Red Hat 8).

After running 'apt-get upgrade -f', I got the following at the end (I
believe this was while apt was trying to remove xanim since that was
the only thing it had left which it hadn't done):
  E: Sub-process /bin/rpm returned an error code (255)

Also, someone suggested rebuilding the database.  I get the following when
trying to do so:
  [root@sobaka rpm]# rpm --rebuilddb
  error: db4 error(16) from dbenv->remove: Device or resource busy

Is there anything else you need to track down this problem?  Is there any way I
can work around this to get rid of this package?  Thanks.

Version-Release number of selected component (if applicable):
rpm-4.2-0.69

How reproducible:
Always
Comment 1 Michael Lee Yohe 2003-08-28 21:52:24 UTC 
Throw the highly verbose -vvvv option on the "-e" line to see what all is going
on.  Attach to this bug the output.
Comment 2 Elijah Newren 2003-08-28 23:08:12 UTC 
Created attachment 94056 [details]
Output from 'rpm -evvvv xanim'
Comment 3 Jeff Johnson 2003-09-10 12:46:23 UTC 
Try --rebuilddb to recreate the package Name index.

Does that fix?
Comment 4 Elijah Newren 2003-09-12 19:02:37 UTC 
No, that doesn't fix the problem:

[root@sobaka root]# rpm -qa | grep xanim
xanim-full-2.80.1-1
[root@sobaka root]# rpm --rebuilddb
error: db4 error(16) from dbenv->remove: Device or resource busy
[root@sobaka root]# rpm -e xanim-full
error: package xanim-full is not installed
[root@sobaka root]# rpm -e xanim
[root@sobaka root]# rpm -qa | grep xanim
xanim-full-2.80.1-1
[root@sobaka root]#
Comment 5 Jeff Johnson 2003-12-27 16:13:23 UTC 
Hmmm, some idiot has apparently hacked rpm to permit '-' characters
in versions, there is no way to get a '-' into version
otherwise.

Verify unambiguously by looking for '-' in the output of
    rpm -q --qf '%{version}' xanim

If there is really a '-' character in version, *please* go shout
at the idiot who produced that package with a modified version of rpm.

The entry in /var/lib/rpm/Packages can be nuked by
running a short program at
    ftp://people.redhat.com/jbj/t38454.c

You will need to edit the program to put in the
header instance number, i.e. the 1st decimal number
in the output of
    rpm -qvv xanim
    ...
    D:  read h#    2035 Header V3 DSA signature: OK, key ID 897da07a

After nuking the package, you will need to remove the files
manually, and do --rebuilddb to get the instance out of the
indices.

Save a tarball of /var/lib/rpm right now, just in case you need
  
Reopen this bug if you need help with t38454.c (btw 38454 is the
bugzilla no. which caused me to write the program, instructions
on compilation and usage there too, possibly slightly old).