Red Hat Bugzilla – Bug 260161
jpackage-utils provides rebuild-security-providers and thus prevents using jpackage
Last modified: 2009-06-25 17:12:32 EDT
Description of problem:
If I try to use jpackage.org packages on Fedora 7, just about nothing will
install because JPackage has a newer jpackage-utils that doesn't provide
The JPackage people say that this isn't their problem, that Fedora shouldn't
ever have put an extra program into jpackage-utils at all. (See
Is it possible to split the program out into its own package somehow?
Version-Release number of selected component (if applicable):
(JPackage has jpackage-utils-1.7.3-2jpp)
Steps to Reproduce:
1. Enable JPackage repository
2. Try to "yum update", or to install anything
Error: Missing Dependency: /usr/bin/rebuild-security-providers is
needed by package java-1.5.0-gcj
I was just about to report the same thing. I've asked on #jpackage and the
strong view is that Fedora is screwing around with their packages.
What is the reason for including rebuild-security-providers? What does it do?
I'm sure it's there for a good reason and I'd just like to understand.
Perhaps Fedora is seeking to package a current stable view of JPackage? That
*would* be fine if they maintained interoperability with JPackage but they don't
- it makes it impossible to install any JPackage-specific package.
JPackage has made great strides in making Java development on Linux a real
possibility - Fedora and RedHat should do everything they can to support them.
(In reply to comment #1)
> What is the reason for including rebuild-security-providers? What does it do?
From the script's header:
# Rebuild the list of security providers in classpath.security
In detail: the script registers external security providers with libgcj. See
Fedora's bouncycastle and java-1.5.0-gcj packages, for usage examples.
I did try to send this change upstream but I got no response:
Now that we're shipping IcedTea we can fix the problem properly, by adding
/etc/java/security/security.d support in the JRE itself.
In the short term, since the script seems to be annoying JPackage users, I guess
I could in-line it wherever it is used, which is now only bouncycastle and
java-1.5.0-gcj (previously gnu-crypto and jessie used it, but they've been
merged into libgcj).
The short-term in-line approach seems like a good one, and having the IcedTea
route in the medium-term would be great.
Thanks very much for responding.
I'd personally mark this as high priority, since it makes using jpackage
I inlined rebuild-security-providers in java-1.5.0-gcj and bouncycastle, then
removed the script from jpackage-utils. Fixed in Rawhide:
*** Bug 441104 has been marked as a duplicate of this bug. ***
still can't install java-1.5.0-gcj in fc8 , with jpackage-utils-1.7.3-1jpp.4.fc9
I have the same problem on RHEL 5.3:
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
# yum install eclipse-jdt eclipse-subclipse
--> Finished Dependency Resolution
java-1.4.2-gcj-compat-184.108.40.206-40jpp.115.x86_64 from rhel-x86_64-server-5 has depsolving problems
--> Missing Dependency: /usr/bin/rebuild-security-providers is needed by package java-1.4.2-gcj-compat-220.127.116.11-40jpp.115.x86_64 (rhel-x86_64-server-5)
Error: Missing Dependency: /usr/bin/rebuild-security-providers is needed by package java-1.4.2-gcj-compat-18.104.22.168-40jpp.115.x86_64 (rhel-x86_64-server-5)
# rpm -q jpackage-utils
# yum provides /usr/bin/rebuild-security-providers
Loaded plugins: fastestmirror, rhnplugin, security
Loading mirror speeds from cached hostfile
* epel: ftp.icm.edu.pl
* jpackage-rhel: ftp.pbone.net
* jpackage-generic: ftp.pbone.net
jpackage-utils-1.7.3-1jpp.2.el5.noarch : JPackage utilities
Filename : /usr/bin/rebuild-security-providers
Could the same fix be done for the RHEL 5 java-1.4.2-gcj package?
I was also hit by this on RHEL 5.3. I opened a new bug for this:
I also included the current workaround I am using:
I comment on bug 497213 to this effect:
jpackage 1.7 works now, but jpackage 5.0 is still broken in the same way... so it's still impossible to use jpackage 5.0