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 22.214.171.124-40jpp_31rh.FC4.1 to
126.96.36.199-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 188.8.131.52-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:
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.