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:
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?
Here it is: $ sudo rpm -ql java-1.4.2-gcj-compat | grep rebuild Password: /usr/bin/rebuild-gcj-db $
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
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
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.
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))
Is regexp by any chance the only package with files in /usr/lib/gcj-4.0.0/classmap.db.d ?
Yes. Here are the contents: $ ls -l total 3444 -rw-r--r-- 1 root root 3522560 Ð¼Ð°Ñ 5 15:21 regexp-1.3.db
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?
> 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.
> 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.
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.
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.
Apparently this bug does not apply anymore. (looked at FC6 and F7). Free to close.
Ok, closing, thanks