Bug 451163 - jpackage sun jdk compat packages incompatibility
jpackage sun jdk compat packages incompatibility
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: chkconfig (Show other bugs)
11
All Linux
low Severity high
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-13 00:03 EDT by Cassio
Modified: 2014-03-16 23:15 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-29 16:12:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Cassio 2008-06-13 00:03:51 EDT
Description of problem:
Compatibility packages provided by jpackage.org have no effect.
For example, package java-1.5.0-sun-compat-1.5.0.14-1jpp.i586.rpm , can be
installed, but produces no effect, i.e. it doesnt add java-1.5.0-sun to
/usr/sbin/alternatives.

Version-Release number of selected component (if applicable):
Version    : 1.7.5
Release    : 1jpp.1.fc9

How reproducible:
Always

Steps to Reproduce:
1. Install jdk-1_5_0_14-linux-i586.rpm provided by Sun at java.sun.com
2. Install java-1.5.0-sun-compat.i586 0:1.5.0.14-1jpp provided by jpackage.org

I receive the following warning about javaws link when I install (dont know if
this is the culprit).

rpm -ivh java-1.5.0-sun-compat-1.5.0.14-1jpp.i586.rpm 
warning: java-1.5.0-sun-compat-1.5.0.14-1jpp.i586.rpm: Header V3 DSA signature:
NOKEY, key ID c431416d
Preparing...                ########################################### [100%]
   1:java-1.5.0-sun-compat  ########################################### [100%]
link /usr/bin/javaws incorrect for slave javaws (/usr/share/javaws javaws)

3. /usr/sbin/alternatives --config java
  
Actual results:
The sun vm option is not shown.
*+ 1           /usr/lib/jvm/jre-1.6.0-openjdk/bin/java
   2           /usr/lib/jvm/jre-1.5.0-gcj/bin/java

Expected results:
The sun vm should be one of the options listed.

Additional info:

I have used exactly the same procedure to install those same versions of
packages in Fedora 8 and RHEL 5 and succeeded. something changed for fedora 9
that broke compatibility with jpackage compat packages.
Comment 1 Thomas Fitzsimmons 2008-06-13 10:44:16 EDT
This seems like an alternatives bug.  If an attempt is made to install a link
with the same name as a previously-installed link, but a different primary path,
then the entire alternatives --install invocation will fail.  A better response
would be to not install only the affected slave symlink.

What changed in Fedora 9:

javaws should not be installed as /usr/share/javaws, it should go in
/usr/lib/jvm/java-$version-$vendor/jre/bin.  We've fixed that in F9's
java-1.6.0-openjdk packages.  This fix, combined with alternatives' behaviour,
cause the conflict with these older JPackage packages.
Comment 2 Cassio 2008-06-13 12:48:44 EDT
Just to add, I tried it with the latest jdk-compat package from jpackage
(java-1.6.0-sun-compat-1.6.0.06-1jpp.i586.rpm), the behavior remains the same --
javaws conflict and no installation of the links.
Comment 3 Bug Zapper 2009-06-09 21:34:59 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Gregory Lee Bartholomew 2009-07-01 17:01:22 EDT
I just now encountered this bug in Fedora 11.  I was trying to install java-1.6.0-sun-compat-1.6.0.06-1jpp.i586.rpm obtained from ftp://jpackage.hmdc.harvard.edu/JPackage/1.7/generic/RPMS.non-free/.  Is there a work around?  I do not seem to have the privileges necessary to change the 'version' of this bug as recommended in the previous post.
Comment 5 Gregory Lee Bartholomew 2009-07-01 18:00:28 EDT
For others who experience this bug in the interim, I found this nosrc rpm on the web: http://ryu.zarb.org/~jasonc/packages/java-1.6.0-sun-1.6.0.13-2jpp.nosrc.rpm

It does work with Fedora 11.  You can find instructions for installing nosrc rpms on the jpackage website: http://www.jpackage.org/nosrc.php

I found this "spec" file to require jdk-6u13-linux-x64.bin obtainable from: http://java.sun.com/products/archive/ (don't execute this jdk binary directly - rather, you put it in a special folder under a directory structure that is created by the "nosrc" rpm and then run the "rpmbuild" command which repackages the binary as a set of rpms).

The directory structure containing the "spec" file may be found somewhere under /usr/src or ~/rpm or ~/rpmbuild depending on how your system is configured.

gb
Comment 6 Bill Nottingham 2009-09-29 16:12:52 EDT
Sorry about the delays. I've looked at this some; it's not really a simple fix.

If you take the route in comment #1 (do not install that particular slave), you're likely to end up with a broken system. After all, if the app is using that path, it likely expects that path, not whatever path the other alternatives-using app uses.

Furthermore, there's no good way to determine which is 'more' correct; it really boils down to which app was installed first - if you installed the Sun JDK first, you'd get the error on installing OpenJDK.

Hence, throwing an error seems the right thing to do here.

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