Bug 162890 - rebuild-gcj-db: command not found error: %postun(regexp-1.3-1jpp_5fc.i386) scriptlet failed, exit status 127
rebuild-gcj-db: command not found error: %postun(regexp-1.3-1jpp_5fc.i386) s...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: java-1.4.2-gcj-compat (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gary Benson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-11 06:51 EDT by Filip Miletic
Modified: 2008-08-02 19:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-05 19:02:29 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 Filip Miletic 2005-07-11 06:51:00 EDT
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 18:07:59 EDT
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 08:54:06 EDT
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 08:58:59 EDT
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 09:09:57 EDT
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 10:19:47 EDT
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 10:54:01 EDT
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 11:59:41 EDT
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 12:09:50 EDT
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 12:28:36 EDT
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 15:03:00 EDT
> 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 05:28:04 EDT
> 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 05:33:00 EDT
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-19 19:52:51 EST
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 07:08:06 EDT
Apparently this bug does not apply anymore. (looked at FC6 and F7).  Free to close.
Comment 15 Christian Iseli 2007-07-05 19:02:29 EDT
Ok, closing, thanks

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