Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162890 - rebuild-gcj-db: command not found error: %postun(regexp-1.3-1jpp_5fc.i386) scriptlet failed, exit status 127
Summary: rebuild-gcj-db: command not found error: %postun(regexp-1.3-1jpp_5fc.i386) s...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.4.2-gcj-compat
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Gary Benson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-11 10:51 UTC by Filip Miletic
Modified: 2008-08-02 23:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-07-05 23:02:29 UTC


Attachments (Terms of Use)

Description Filip Miletic 2005-07-11 10:51:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; sr-YU; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
When trying to uninstall the regexp package from FC4, the following error occurs.

/var/tmp/rpm-tmp.85574: line 1: rebuild-gcj-db: command not found
error: %postun(regexp-1.3-1jpp_5fc.i386) scriptlet failed, exit status 127

Version-Release number of selected component (if applicable):
regexp-1.3-1jpp_5fc

How reproducible:
Always

Steps to Reproduce:
1. Install regexp and the dependencies
2. Try to uninstall regexp
  

Actual Results:  The removal procedure prints the error given above and aborts the removal.

Expected Results:  The package should have been removed.

Additional info:

Comment 1 Vadim Nasardinov 2005-07-12 22:07:59 UTC
Hmmm, that's odd.  In theory, the above error shouldn't be possible.
If you hadn't used the --force or --nodeps options when installing the
regexp RPM and its dependencies, then you should have the
java-1.4.2-gcj-compat package on your system.  The latter ships
/usr/bin/rebuild-gcj-db.  Therefore, the postun script should not fail
with the reported error.

| $ rpm -q --requires regexp | grep gcj-compat
| java-1.4.2-gcj-compat >= 1.4.2.0-40jpp_16rh
| $ rpm -ql java-1.4.2-gcj-compat | grep rebuild
| /usr/bin/rebuild-gcj-db

That's the theory.  In practice, I don't have a quick way of testing
the uninstallation of the regexp RPM. The only FC4 box that I have
access to at the moment has a bunch of other RPMs installed that
depend on the regexp package, thus preventing me from uninstalling it.

So, before I try getting access to a freshly set up FC4 box that
doesn't yet have regexp installed on it, can you please run

 $ rpm -ql java-1.4.2-gcj-compat | grep rebuild

and post the result here?


Comment 2 Filip Miletic 2005-07-13 12:54:06 UTC
Here it is:

$ sudo rpm -ql java-1.4.2-gcj-compat | grep rebuild
Password:
/usr/bin/rebuild-gcj-db
$ 

Comment 3 Filip Miletic 2005-07-13 12:58:59 UTC
Mind you that I don't actually want the gcj-compat package present on the
machine as it interferes with Sun's J2DK that I use.

The regexp and gcj-compat were installed during upgrade from FC3 to FC4 (i.e. I
was not asked!) and gcj-compat breaks the J2DK. So I wanted to uninstall
gcj-compat with all dependencies thereof. 

Only the regexp package could not be uninstalled due to the mentioned error.
Thus the only way I can have NO confusion with J2SDK is to leave the 'regexp'
package sitting around with unsatisfied dependencies.

f


Comment 4 Filip Miletic 2005-07-13 13:09:57 UTC
Here is what I get after installing all the dependencies for regexp (gcj-compat
and jessie) and trying to uninstall regexp only:


gcj-dbtool: Manipulate gcj map database files

  Usage: 
    gcj-dbtool -n file.gcjdb [size]     - Create a new gcj map database
    gcj-dbtool -a file.gcjdb file.jar file.so
            - Add the contents of file.jar to a gcj map database
    gcj-dbtool -f file.gcjdb file.jar file.so
            - Add the contents of file.jar to a gcj map database
    gcj-dbtool -t file.gcjdb            - Test a gcj map database
    gcj-dbtool -l file.gcjdb            - List a gcj map database
    gcj-dbtool [-][-0] -m dest.gcjdb [source.gcjdb]...
            - Merge gcj map databases into dest
              Replaces dest
              To add to dest, include dest in the list of sources
              If the first arg is -, read the list from stdin
              If the first arg is -0, filenames separated by nul
    gcj-dbtool -p [LIBDIR]              - Print default database name
error: %postun(regexp-1.3-1jpp_5fc.i386) scriptlet failed, exit status 123
W: Some errors occurred while running transaction


Comment 5 Vadim Nasardinov 2005-07-13 14:19:47 UTC
Let's see if I can sort this out.

In comment #3, you basically say that you had forcibly uninstalled the
java-1.4.2-gcj-compat package despite the fact that it's a required
dependency for the regexp package.  Since a system with broken
dependencies cannot be expected to work, I'm leaning towards closing
this ticket as NOTABUG.

Before I do that, let's address the remaining issues.

You say that the reason you don't want java-1.4.2-gcj-compat on your
system is because it interferes with Sun's JDK.  There are at least
two workarounds.

 1. Build a Sun JDK RPM using the JPackage SRPM matching your
    preferred JDK version.  For example,
      http://www.jpackage.org/rpm.php?id=2427

    Once you have the binary RPM, install it and you should be good to
    go.  FC4 allows you to use multiple JDKs which are managed via the
    alternatives system -- see ALTERNATIVES(8).  Sun's JDK has a
    higher priority than GCJ.  Your /usr/bin/java and friends should
    now be pointing to the corresponding Sun binaries.

    See also
    http://fedoranews.org/mediawiki/index.php/JPackage_Java_for_FC4

 2. If you install Sun's JDK manually into, say,
    /usr/local/j2sdk1.4.2_08 or some such, you can probably make it
    your preferred JDK without messing with the alternatives system,
    if you follow these steps:

      (a) Set JAVA_HOME to /usr/local/j2sdk1.4.2_08 in your
          ~/.bash_profile

      (b) Make sure $JAVA_HOME/bin appears on your PATH before
          /usr/bin

In any case, there is no real need to uninstall java-1.4.2-gcj-compat.

As for the error you reported in comment #4, can you post the output
of the following commands?

 $  rpm -q --scripts regexp
 $ rpm -q $(rpm -qf $(which rebuild-gcj-db))

Also can you run the "rpm -e" command with the -vv flag and see if it
shows the exact command(s) that the postun scriptlet is attempting to
execute?  Be sure to post your exact "rpm -e -vv" command here.


Comment 6 Filip Miletic 2005-07-13 14:54:01 UTC
Thanks for the helpful hints. Now on to the comments.

Yes indeed, the reason I wanted to uninstall gcj-compat is that it interferes
with the J2SDK. 

I am aware that there are solutions that allow J2SDK to coexist with gcj-compat.
But I don't want these two to coexist. I want to uninstall gcj-compat. The
actual reason for the removal should not matter.

The uninstall should be possible, provided that all dependencies are removed
too. However, since the 'regexp', a dependency of gcj-compat, cannot be
uninstalled, gcj-compat cannot be uninstalled too. That's the reason for this
report.

I use apt-get to automate package management. As it uses rpm internally, the
results should be the same as running rpm in the correct order. I thus never
_forced_ the uninstalls. 

When asking apt-get to uninstall gcj-compat, it says that a removal transaction
should remove packages: regexp, gcj-compat and jessie. I agree and tell apt-get
to proceed. However, as regexp uninstall fails, the whole transaction is
aborted. Net result: gcj-compat cannot be uninstalled cleanly.

Here are the results you required. Packages gcj-compat, jessie and regexp are
installed on the system before the following lines have been printed. Note that
the database rebuild step prints usage.

$ rpm -q --scripts regexp
preinstall scriptlet (using /bin/sh):
rm -f /usr/share/java/jakarta-regexp.jar
rm -f /usr/share/java/regexp.jar
postinstall scriptlet (using /bin/sh):
rebuild-gcj-db /usr/lib
postuninstall scriptlet (using /bin/sh):
rebuild-gcj-db /usr/lib


-

$ rpm -q $(rpm -qf $(which rebuild-gcj-db))
java-1.4.2-gcj-compat-1.4.2.0-40jpp_31rh


-
$ rpm -e -vv regexp
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
D: locked   db index       /var/lib/rpm/Packages
D: opening  db index       /var/lib/rpm/Name rdonly mode=0x0
D: opening  db index       /var/lib/rpm/Pubkeys rdonly mode=0x0
D:  read h#     512 Header sanity check: OK
D: ========== DSA pubkey id b44269d0 4f2a6fd2 (h#512)
D:  read h#    3948 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: ========== --- regexp-1.3-1jpp_5fc i386/linux 0x1
D: opening  db index       /var/lib/rpm/Requirename rdonly mode=0x0
D: ========== recording tsort relations
D: ========== tsorting packages (order, #predecessors, #succesors, tree, depth,
breadth)
D:     0    0    0    0    1    0   -regexp-1.3-1jpp_5fc.i386
D: closed   db index       /var/lib/rpm/Pubkeys
D: closed   db index       /var/lib/rpm/Requirename
D: closed   db index       /var/lib/rpm/Name
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages create mode=0x42
D: mounted filesystems:
D:     i        dev    bsize       bavail       iavail mount point
D:     0 0x00000303     4096      1825230      6673341 /
D:     1 0x00000003     4096            0           -1 /proc
D:     2 0x00000000     4096            0           -1 /sys
D:     3 0x0000000a     4096            0           -1 /dev/pts
D:     4 0x00000011     4096        64290        64289 /dev/shm
D:     5 0x00000012     4096            0           -1 /proc/sys/fs/binfmt_misc
D:     6 0x00000013     4096            0           -1 /misc
D:     7 0x00000014     4096            0           -1 /net
D: sanity checking 1 elements
D: running pre-transaction scripts
D: computing 7 file fingerprints
D: computing file dispositions
D: opening  db index       /var/lib/rpm/Basenames create mode=0x42
D: ========== --- regexp-1.3-1jpp_5fc i386-linux 0x1
D:     erase: regexp-1.3-1jpp_5fc has 7 files, test = 0
D: opening  db index       /var/lib/rpm/Name create mode=0x42
D:  read h#    3948 Header V3 DSA signature: OK, key ID 4f2a6fd2
D: opening  db index       /var/lib/rpm/Triggername create mode=0x42
D: fini      120644  1 (   0,   0)        14 /usr/share/java/regexp.jar
D: fini      100644  1 (   0,   0)     25350 /usr/share/java/regexp-1.3.jar
D: fini      100644  1 (   0,   0)      2674 /usr/share/doc/regexp-1.3/LICENSE.txt
D: fini      040755  2 (   0,   0)      4096 /usr/share/doc/regexp-1.3
D: fini      120755  1 (   0,   0)        20 /usr/lib/libregexp.jar.so
D: fini      100755  1 (   0,   0)    124984 /usr/lib/libregexp-1.3.jar.so
D: fini      100644  1 (   0,   0)   3522560
/usr/lib/gcj-4.0.0/classmap.db.d/regexp-1.3.db
D:     erase: %postun(regexp-1.3-1jpp_5fc.i386) asynchronous scriptlet start
D:     erase: %postun(regexp-1.3-1jpp_5fc.i386) execv(/bin/sh) pid 10244
+ rebuild-gcj-db /usr/lib
gcj-dbtool: Manipulate gcj map database files

  Usage:
    gcj-dbtool -n file.gcjdb [size]     - Create a new gcj map database
    gcj-dbtool -a file.gcjdb file.jar file.so
            - Add the contents of file.jar to a gcj map database
    gcj-dbtool -f file.gcjdb file.jar file.so
            - Add the contents of file.jar to a gcj map database
    gcj-dbtool -t file.gcjdb            - Test a gcj map database
    gcj-dbtool -l file.gcjdb            - List a gcj map database
    gcj-dbtool [-][-0] -m dest.gcjdb [source.gcjdb]...
            - Merge gcj map databases into dest
              Replaces dest
              To add to dest, include dest in the list of sources
              If the first arg is -, read the list from stdin
              If the first arg is -0, filenames separated by nul
    gcj-dbtool -p [LIBDIR]              - Print default database name
D:     erase: waitpid(10244) rc 10244 status 7b00 secs 0.197
greška: %postun(regexp-1.3-1jpp_5fc.i386) scriptlet failed, exit status 123
D: running post-transaction scripts
D: closed   db index       /var/lib/rpm/Triggername
D: closed   db index       /var/lib/rpm/Basenames
D: closed   db index       /var/lib/rpm/Name
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: May free Score board((nil))



Comment 7 Gary Benson 2005-07-13 15:59:41 UTC
Is regexp by any chance the only package with files in
/usr/lib/gcj-4.0.0/classmap.db.d ?

Comment 8 Filip Miletic 2005-07-13 16:09:50 UTC
Yes. Here are the contents:

$ ls -l
total 3444
-rw-r--r--  1 root root 3522560 Ð¼Ð°Ñ  5 15:21 regexp-1.3.db



Comment 9 Gary Benson 2005-07-13 16:28:36 UTC
Ok, so the original "rebuild-gcj-db: command not found" error you were getting
was I guess caused by bug 89740.  The usage message is caused because
rebuild-gcj-db fails when /usr/lib/gcj-4.0.0/classmap.db.d is empty.  Neither
are critical even if you do intend to use java-gcj-compat as your JRE so you can
safely ignore them.

Has that resolved your problem?

Comment 10 Filip Miletic 2005-07-13 19:03:00 UTC
> Has that resolved your problem?

Good that there is an explanation now as to why this fails. However, the regexp
package still cannot be cleanly removed. 

If I understand correctly, whichever package is left last in the gcj database
cannot be removed cleanly.

This still seems as a bug to me. IMHO the uninstaller script should handle the
case when no packages are left.

Comment 11 Gary Benson 2005-07-14 09:28:04 UTC
> the uninstaller script should handle the case when no packages are left.

Of course, and it'll get fixed.  I just wanted to make sure you weren't stuck
with a broken system because I have a couple of big things I need to do before
I'll have time for this.

Comment 12 Filip Miletic 2005-07-14 09:33:00 UTC
Thanks for the concern. 

The box seems to be working fine for the time being. I am unsure though whether
the broken package would have implications on further installs. So far I haven't
seen anything being broken beyond repair.

Comment 13 Christian Iseli 2007-01-20 00:52:51 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Comment 14 Filip Miletic 2007-06-25 11:08:06 UTC
Apparently this bug does not apply anymore. (looked at FC6 and F7).  Free to close.

Comment 15 Christian Iseli 2007-07-05 23:02:29 UTC
Ok, closing, thanks


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