Bug 1030634

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.

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)?

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)

(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?

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).

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.

(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.

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).

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.

# 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?

[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?

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?

> 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?

(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.

>> 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

Re-opening, re-assigning to Jiri and setting request flags.

> 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.

(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

Jiri, thanks for the quick response.

That makes sense, and clarifies things nicely for me.

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

Closing as it is addressed as of java-1.7.0-openjdk-1:1.7.0.51-2.4.4.1.el6_5