Bug 260161 - jpackage-utils provides rebuild-security-providers and thus prevents using jpackage
jpackage-utils provides rebuild-security-providers and thus prevents using jp...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: jpackage-utils (Show other bugs)
7
All All
medium Severity low
: ---
: ---
Assigned To: Thomas Fitzsimmons
Fedora Extras Quality Assurance
:
: 441104 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-28 09:28 EDT by Mary Ellen Foster
Modified: 2009-06-25 17:12 EDT (History)
7 users (show)

See Also:
Fixed In Version: 1.7.3-1jpp.4.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-22 14:58:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JPackage 289 None None None Never

  None (edit)
Description Mary Ellen Foster 2007-08-28 09:28:30 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
/usr/bin/rebuild-security-providers.

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
https://www.zarb.org/pipermail/jpackage-discuss/2007-June/011537.html)

Is it possible to split the program out into its own package somehow?

Version-Release number of selected component (if applicable):
jpackage-utils-1.7.3-1jpp.3.fc7
(JPackage has jpackage-utils-1.7.3-2jpp)

How reproducible:
Always

Steps to Reproduce:
1. Enable JPackage repository
2. Try to "yum update", or to install anything
  
Actual results:
...
Error: Missing Dependency: /usr/bin/rebuild-security-providers is
needed by package java-1.5.0-gcj

Expected results:
Successful interoperability

Additional info:
Comment 1 Nick Pierpoint 2007-10-19 05:02:32 EDT
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.
Comment 2 Thomas Fitzsimmons 2007-10-19 15:39:13 EDT
(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:

https://zarb.org/pipermail/jpackage-discuss/2006-February/009592.html

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).
Comment 3 Nick Pierpoint 2007-10-20 13:19:55 EDT
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.
Comment 4 Luis Villa 2007-11-03 09:22:55 EDT
I'd personally mark this as high priority, since it makes using jpackage
~impossible.
Comment 5 Thomas Fitzsimmons 2008-01-22 14:58:28 EST
I inlined rebuild-security-providers in java-1.5.0-gcj and bouncycastle, then
removed the script from jpackage-utils.  Fixed in Rawhide:

jpackage-utils-1.7.3-1jpp.4.fc9
Comment 6 Thomas Fitzsimmons 2008-04-10 11:44:30 EDT
*** Bug 441104 has been marked as a duplicate of this bug. ***
Comment 7 Sergio Monteiro Basto 2008-07-19 07:56:13 EDT
still can't install java-1.5.0-gcj in fc8 , with jpackage-utils-1.7.3-1jpp.4.fc9 
Comment 8 Aleksander Adamowski 2009-04-06 07:14:36 EDT
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-1.4.2.0-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-1.4.2.0-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-1.4.2.0-40jpp.115.x86_64 (rhel-x86_64-server-5)

# rpm -q jpackage-utils
jpackage-utils-1.7.5-1jpp

# 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
Matched from:
Filename    : /usr/bin/rebuild-security-providers

Could the same fix be done for the RHEL 5 java-1.4.2-gcj package?
Comment 9 Daniel Qarras 2009-04-22 15:53:09 EDT
I was also hit by this on RHEL 5.3. I opened a new bug for this:

https://bugzilla.redhat.com/show_bug.cgi?id=497213

I also included the current workaround I am using:

http://www.zarb.org/pipermail/jpackage-discuss/2008-July/012751.html
Comment 10 Craig 2009-06-25 17:12:32 EDT
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

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