Hide Forgot
I was under the impression (perhaps mistakenly) that Fedora Core was trying to be compatible with the JPackage.org regarding java packages. So I had no qualms about enabling the jpackage repo in yum. Around a month ago, jpackage-utils was updated to 1.6.6-1jpp from that repo. The JPackage.org version of this package, unlike the fedora version, does not contain the /usr/bin/rebuild-security-providers script. As a result of this, when it came time to upgrade java-1.4.2-gcj-compat from 1.4.2.0-40jpp_31rh.FC4.1 to 1.4.2.0-40jpp_31rh.FC4.2, the %postun script, which calls /usr/bin/rebuild-security-providers, failed, and I was left with both versions of this package installed. I removed 1.4.2.0-40jpp_31rh.FC4.1 manually using rpm -e --noscripts, but I don't think I should have needed to do this. I guess the "quick fix" for this would be to add "|| :" at the end of the line calling /usr/bin/rebuild-security-providers, and the better (or additional) fix would be to push the /usr/bin/rebuild-security-providers script upstream so that the jpackage-utils package contained what was needed, no matter where it came from. If that can't be done, perhaps add: Requires(post): /usr/bin/rebuild-security-providers Requires(postun): /usr/bin/rebuild-security-providers That should then prevent the installation of conflicting packages on systems that don't already have them.
Yes, I'm going to remove this incompatibility from the Fedora jpackage-utils in the next import. In fact, I hope to make our next jpackage-utils exactly match the upstream jpackage-utils. I'll leave this bug open until this incompatibility is gone.
I've updated all the Fedora packages that call rebuild-security-providers to check for the script's existence before calling it, and I've submitted the script upstream for inclusion in the official jpackage-utils package. Closing.