Bug 1030634 - java-1.7.0-openjdk provides changed from java7 to java
java-1.7.0-openjdk provides changed from java7 to java
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: java-1.7.0-openjdk (Show other bugs)
6.5
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: jiri vanek
BaseOS QE - Apps
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-14 15:21 EST by Matt Spaulding
Modified: 2014-03-17 10:51 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-17 10:44:16 EDT
Type: Bug
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 Matt Spaulding 2013-11-14 15:21:03 EST
Description of problem:
With RHEL 6.4, java-1.7.0-openjdk provides "java7 = 1:1.7.0". In the RHEL 6.5 beta, this has changed to "java = 1:1.7.0" which breaks packages that depend on the java7 provides.

Version-Release number of selected component (if applicable):
java-1.7.0-openjdk-1.7.0.40-2.4.2.1.el6

Actual results:
The package provides "java = 1:1.7.0".

Expected results:
The package provides both "java = 1:1.7.0" and "java7 = 1:1.7.0".
Comment 1 Deepak Bhole 2013-11-14 15:27:53 EST
Hi Matt,

This change is intentional. There shouldn't have been any packages dependent on java7 -- they should have relied on java-1.7.0-openjdk not java7.

java7 was always intended to be temporary just as it was in Fedora and just as java8 is now in Fedora 19/20/21.
Comment 2 Matt Spaulding 2013-11-14 17:51:22 EST
Ok. I thought that there would be a period of time where both java and java7 provides would be available to allow for a transition. The Java packaging guidelines for Fedora state that packages should require java and java-devel. I assumed that since java7 and java7-devel were the most similar that they were the correct choice.

Is it documented somewhere to use java-1.7.0-openjdk instead of java (or java7)?
Comment 3 Deepak Bhole 2013-11-18 16:00:42 EST
There was never a time in Fedora where a newer OpenJDK (than is default) was needed, so this issue never arose. I understand the need for documentation however and I will ask one of our engineers to bring this up with the SIG to make it more official (that java-1.X.0-openjdk be required instead of javaX and that it is the packagers responsibility to update that once the new OpenJDK becomes the default)
Comment 4 Severin Gehwolf 2013-11-21 04:42:12 EST
(In reply to Matt Spaulding from comment #2)
> Ok. I thought that there would be a period of time where both java and java7
> provides would be available to allow for a transition.

Since I've come across a similar issue recently. I think the way it was implemented it didn't allow for a smooth transition. I would have expected for the openjdk package to provide java *and* java7 for a transition period. Sure, one could explicitly require java-1.x.0-openjdk, but how about a library which works fine with oracle/ibm Java 7?

Here are the provides I see in java-1.7.0-openjdk (note no provides for *java*):
$ rpm -q java-1.7.0-openjdk
java-1.7.0-openjdk-1.7.0.45-2.4.3.2.el6_4.x86_64
$ rpm -q --provides java-1.7.0-openjdk | grep java | grep -v java7
config(java-1.7.0-openjdk) = 1:1.7.0.45-2.4.3.2.el6_4
libjava.so()(64bit)  
libjava.so(SUNWprivate_1.1)(64bit)  
libjava_crw_demo.so()(64bit)  
libjava_crw_demo.so(SUNWprivate_1.1)(64bit)  
libjavajpeg.so()(64bit)  
libjavajpeg.so(SUNWprivate_1.1)(64bit)  
libjavalcms.so()(64bit)  
libjavalcms.so(SUNWprivate_1.1)(64bit)  
libpulse-java.so()(64bit)  
java-1.7.0-openjdk = 1:1.7.0.45-2.4.3.2.el6_4
java-1.7.0-openjdk(x86-64) = 1:1.7.0.45-2.4.3.2.el6_4

What does this mean? Packages which used to require java7 will be broken with RHEL 6.5's java-1.7.0-openjdk. If they hadn't done a "Require: java7" they'd be explicitly tied to openjdk (which they perhaps didn't want either). Had they tried "Require: java >= 1:1.7.0" on RHEL 6.4, the openjdk package would not have satisfied this require.

Is this really intentional?
Comment 5 Deepak Bhole 2013-11-21 10:03:34 EST
Perhaps I should step back a bit here. This thing is, the java7 provides was a mistake. We did it because we did not want Koji/Brew to pull in JDK7 at the time. However we realized that providing just java would not cause any issues as it is was only java-devel that mattered. That is why we changed it back, so that 'java' is always provided, but the devel version still provides 'java7-devel'. 

This allows applications to require "java" and they will continue to work fine with 6 or 7. We did not see this as much of a problem because in base RHEL, everything is always built with OpenJDK6 as that is the default JDK.

The java provision will be the norm going forward (i.e. java-1.8.0-openjdk will provide java and java8-devel).
Comment 6 Deepak Bhole 2013-11-21 10:08:34 EST
Actually, on second thought, perhaps providing 'java' prematurely is not a good idea.

I just realized that the OpenJDK8 RPM only provides java8 and the more I think about it, it makes sense. If it were to provide 'java', yum will see it as satisfying dependencies and may start to install that instead of OpenJDK7, which is a problem from a functionality standpoint (8 is still WIP) and from a security standpoint as well.

I think the change to provide 'java' should only happen after a stable release. In RHEL, this may be an additional delay before we make such a switch.
Comment 7 Severin Gehwolf 2013-11-21 10:36:40 EST
(In reply to Deepak Bhole from comment #6)
> Actually, on second thought, perhaps providing 'java' prematurely is not a
> good idea.

Agreed.

> I just realized that the OpenJDK8 RPM only provides java8 and the more I
> think about it, it makes sense. If it were to provide 'java', yum will see
> it as satisfying dependencies and may start to install that instead of
> OpenJDK7, which is a problem from a functionality standpoint (8 is still
> WIP) and from a security standpoint as well.
> 
> I think the change to provide 'java' should only happen after a stable
> release. In RHEL, this may be an additional delay before we make such a
> switch.

Right. What I'd like to point out, though, is that *stable* java-1.7.0-openjdk did *not* provide java (only java7). In future, once an openjdk release reaches stable it should have a "Provides: java >= 1:1.x.0". That didn't seem to have happened for latest java-1.7.0-openjdk in RHEL 6.4.
Comment 8 Matyas Selmeci 2013-12-03 12:37:29 EST
Where I work, we've built several packages against the java7 virtual dependency. We needed to build specifically against Java 7 since Java 6 was EOL'ed, but we wanted to give our users the option to choose their Java 7 implementation. What should we have done instead that would have still satisfied these requirements?

Also, are you going to make this same change for RHEL 5, and if so, when? Since we support both RHEL 5 and RHEL 6, we'd like to know how long we have to patch things up (and how we can make a smooth transition for our users).
Comment 9 jiri vanek 2013-12-09 04:53:17 EST
All jdks have:

where javaver is 1.7.0 or 1.6.0
origin is oracle, ibm or openjdk


Provides: jre-%{javaver}-%{origin} = %{epoch}:%{version}-%{release}
Provides: jre-%{origin} = %{epoch}:%{version}-%{release}
Provides: jre-%{javaver} = %{epoch}:%{version}-%{release}
Provides: java-%{javaver} = %{epoch}:%{version}-%{release}
Provides: jre = %{javaver}
Provides: java-%{origin} = %{epoch}:%{version}-%{release}
Provides: java = %{epoch}:%{javaver}

So requires java-1.7.0 should solve those issues.

Yes, provide java7 was mistake. But there really should not be need to add it back.
Comment 10 Matyas Selmeci 2013-12-09 13:45:45 EST
# repoquery --plugins --whatprovides java-1.7.0
(no output)
# repoquery --plugins --whatprovides java-1.7.0-openjdk
java-1.7.0-openjdk-1:1.7.0.9-2.3.4.1.el6_3.x86_64
java-1.7.0-openjdk-1:1.7.0.9-2.3.4.1.el6_3.x86_64

When was the java-%{javaver} provides introduced?
Comment 11 jiri vanek 2013-12-10 09:54:01 EST
[jvanek@jvanek ~]$ repoquery --plugins --whatprovides java-1.7.0-openjdk
java-1.7.0-openjdk-1:1.7.0.25-2.3.10.3.fc19.x86_64
java-1.7.0-openjdk-1:1.7.0.60-2.4.3.0.fc19.x86_64
[jvanek@jvanek ~]$ repoquery --plugins --whatprovides java-1.7.0
java-1.7.0-openjdk-1:1.7.0.25-2.3.10.3.fc19.x86_64
java-1.7.0-openjdk-1:1.7.0.60-2.4.3.0.fc19.x86_64


yes, with unhappy java7 it was "java7-1.7.0-openjdk".

Is the "new" approach java-1.7.0 enough for you?
Comment 12 Matyas Selmeci 2013-12-10 13:01:08 EST
Sadly it's a little late for that. We've worked around the issue by creating a shim package that bridges the two virtual dependencies via Requires/Provides.

What are your plans regarding Java 8? You mentioned that you plan to use the "java8" virtual dependency and switch it to "java" once Java 8 is declared stable, but if I were to depend on "java-1.8.0", will it work both before and after the switchover?
Comment 13 jiri vanek 2013-12-11 03:03:20 EST
> yes, with unhappy java7 it was "java7-1.7.0-openjdk".
nd was also java7-1.7.0 :( 

For java8 it is still not yet decided. Although we found java7 very bad, we still do not have an substitution.  If we will go with java8, then I would say yes, but just in places where do not appear version. So the above "table" would be like:

Provides: jre-%{javaver}-%{origin} = %{epoch}:%{version}-%{release}
Provides: jre8-%{origin} = %{epoch}:%{version}-%{release}
Provides: jre-%{javaver} = %{epoch}:%{version}-%{release}
Provides: java-%{javaver} = %{epoch}:%{version}-%{release}
Provides: jre8 = %{javaver}
Provides: java8-%{origin} = %{epoch}:%{version}-%{release}
Provides: java8 = %{epoch}:%{javaver}

But please, this is something what just crossed my mind :)

> Sadly it's a little late for that. We've worked around the issue by creating a 
> shim package that bridges the two virtual dependencies via Requires/Provides.

Do you wont us to put java7 back?
Comment 14 Matyas Selmeci 2013-12-11 20:14:42 EST
(In reply to jiri vanek from comment #13)
> > yes, with unhappy java7 it was "java7-1.7.0-openjdk".
> nd was also java7-1.7.0 :( 
> 
> For java8 it is still not yet decided. Although we found java7 very bad, we
> still do not have an substitution.  If we will go with java8, then I would
> say yes, but just in places where do not appear version. So the above
> "table" would be like:
> 
> Provides: jre-%{javaver}-%{origin} = %{epoch}:%{version}-%{release}
> Provides: jre8-%{origin} = %{epoch}:%{version}-%{release}
> Provides: jre-%{javaver} = %{epoch}:%{version}-%{release}
> Provides: java-%{javaver} = %{epoch}:%{version}-%{release}
> Provides: jre8 = %{javaver}
> Provides: java8-%{origin} = %{epoch}:%{version}-%{release}
> Provides: java8 = %{epoch}:%{javaver}
> 
> But please, this is something what just crossed my mind :)

Any of these would be fine, as long as they are kept around even after Java 8 becomes the default.

> > Sadly it's a little late for that. We've worked around the issue by creating a 
> > shim package that bridges the two virtual dependencies via Requires/Provides.
> 
> Do you wont us to put java7 back?

Yes, please. That would be very helpful.
Comment 15 Dave Cahill 2013-12-11 20:49:27 EST
>> Where I work, we've built several packages against the java7 virtual
>> dependency. We needed to build specifically against Java 7 since Java 6 was
>> EOL'ed, but we wanted to give our users the option to choose their Java 7
>> implementation.

We are seeing the exact same issue.

>> Do you wont us to put java7 back?
> Yes, please. That would be very helpful.

+1
Comment 16 Deepak Bhole 2013-12-12 11:19:23 EST
Re-opening, re-assigning to Jiri and setting request flags.
Comment 17 Dave Cahill 2013-12-18 00:00:39 EST
> Do you wont us to put java7 back?

Is this likely to happen? If so, is there any timeline for a decision / implementation?

I'm trying to figure out if we should recommend in our docs that people install our shim package to workaround, or if this will be resolved soon.
Comment 18 jiri vanek 2013-12-18 02:22:29 EST
(In reply to Dave Cahill from comment #17)
> > Do you wont us to put java7 back?
> 
> Is this likely to happen? If so, is there any timeline for a decision /
> implementation?

Unless something change, I  will include this in january CPU[1] I'm afraid there is no way how to force it earlier.

[1] http://www.oracle.com/technetwork/topics/security/alerts-086861.html
Comment 19 Dave Cahill 2013-12-18 02:25:13 EST
Jiri, thanks for the quick response.

That makes sense, and clarifies things nicely for me.
Comment 24 Sascha Homeier 2014-01-15 08:22:44 EST
Seems like the CPU which rolled out today contains the "java7"-change:
http://rhn.redhat.com/errata/RHSA-2014-0026.html

...
Note: The java-1.7.0-openjdk package shipped with Red Hat Enterprise Linux
6.5 via RHBA-2013:1611 replaced "java7" with "java" in the provides list.
This update re-adds "java7" to the provides list to maintain backwards
compatibility with releases prior to Red Hat Enterprise Linux 6.5.
...

Thx for changing that. It also solved some problems we had at our company ;)

Cheers
Sascha
Comment 27 Deepak Bhole 2014-03-17 10:44:16 EDT
Closing as it is addressed as of java-1.7.0-openjdk-1:1.7.0.51-2.4.4.1.el6_5

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