Bug 1217177

hi!

Since rhel-7  this naming is affecting *all* jdks. (6/7/8 x oepnjdk/oracle/ibm).
As jdk8 was designed for rhel7 and later backported to rhel6 it is keeping its name convention.

The reason is, that you can have more same jdks installed in parallel. And even "minor" release ++ can have an crucial patch.


> This can adversely affect existing applications that expect a consistent Java naming scheme. 

It should not. You should use the links pointing to those dirs. And those links are still kept.

Here's the definition for the links for java-1.6.0-openjdk.spec

# Standard JPackage naming and versioning defines.
%define origin          openjdk
%define priority        16000
%define javaver         1.6.0
%define buildver        0

# Standard JPackage directories and symbolic links.
# Make 64-bit JDKs just another alternative on 64-bit architectures.
%ifarch %{multilib_arches}
%define sdklnk          java-%{javaver}-%{origin}.%{_arch}
%define jrelnk          jre-%{javaver}-%{origin}.%{_arch}
%define sdkdir          %{name}-%{version}.%{_arch}
%else
%define sdklnk          java-%{javaver}-%{origin}
%define jrelnk          jre-%{javaver}-%{origin}
%define sdkdir          %{name}-%{version}
%endif
%define jredir          %{sdkdir}/jre
%define sdkbindir       %{_jvmdir}/%{sdklnk}/bin
%define jrebindir       %{_jvmdir}/%{jrelnk}/bin
%ifarch %{multilib_arches}
%define jvmjardir       %{_jvmjardir}/%{name}-%{version}.%{_arch}
%else
%define jvmjardir       %{_jvmjardir}/%{name}-%{version}
%endif


and the diffs between java-1.6.0-openjdk.spec java-1.7.0-openjdk.spec

140,142c140,142         
< %define sdklnk          java-%{javaver}-%{origin}.%{_arch}
< %define jrelnk          jre-%{javaver}-%{origin}.%{_arch}
< %define sdkdir          %{name}-%{version}.%{_arch}
---
> %global sdklnk          java-%{javaver}-%{origin}.%{_arch}
> %global jrelnk          jre-%{javaver}-%{origin}.%{_arch}
> %global sdkdir          %{name}-%{version}.%{_arch}
144,150c144,150
< %define sdklnk          java-%{javaver}-%{origin}
< %define jrelnk          jre-%{javaver}-%{origin}
< %define sdkdir          %{name}-%{version}
< %endif
< %define jredir          %{sdkdir}/jre
< %define sdkbindir       %{_jvmdir}/%{sdklnk}/bin
< %define jrebindir       %{_jvmdir}/%{jrelnk}/bin
---
> %global sdklnk          java-%{javaver}-%{origin}
> %global jrelnk          jre-%{javaver}-%{origin}
> %global sdkdir          %{name}-%{version}
> %endif
> %global jredir          %{sdkdir}/jre
> %global sdkbindir       %{_jvmdir}/%{sdklnk}/bin
> %global jrebindir       %{_jvmdir}/%{jrelnk}/bin
152c152
< %define jvmjardir       %{_jvmjardir}/%{name}-%{version}.%{_arch}
---
> %global jvmjardir       %{_jvmjardir}/%{name}-%{version}.%{_arch}
154c154
< %define jvmjardir       %{_jvmjardir}/%{name}-%{version}
---
> %global jvmjardir       %{_jvmjardir}/%{name}-%{version}
156a157,160


It's basically trivial.

Here's the diffs between java-1.7.0-openjdk.spec and java-1.8.0-openjdk.spec

Note that jrelnk wsa redefined from:

< %global jrelnk          jre-%{javaver}-%{origin}.%{_arch}

to

> %global jrelnk          jre-%{javaver}-%{origin}-%{version}-%{release}.%{_arch}


Which is inconsistent with previous releases.

Either this needs to be fixed, OR something needs to be put into the release notes that documents this change.

138,155c104,105
< # Make 64-bit JDKs just another alternative on 64-bit architectures.
< %ifarch %{multilib_arches}
< %global sdklnk          java-%{javaver}-%{origin}.%{_arch}
< %global jrelnk          jre-%{javaver}-%{origin}.%{_arch} ### <---- NOTE
< %global sdkdir          %{name}-%{version}.%{_arch}
< %else
< %global sdklnk          java-%{javaver}-%{origin}
< %global jrelnk          jre-%{javaver}-%{origin}
< %global sdkdir          %{name}-%{version}
< %endif
< %global jredir          %{sdkdir}/jre
< %global sdkbindir       %{_jvmdir}/%{sdklnk}/bin
< %global jrebindir       %{_jvmdir}/%{jrelnk}/bin
< %ifarch %{multilib_arches}
< %global jvmjardir       %{_jvmjardir}/%{name}-%{version}.%{_arch}
< %else
< %global jvmjardir       %{_jvmjardir}/%{name}-%{version}
< %endif
---
> %global sdkdir          %{uniquesuffix}
> %global jrelnk          jre-%{javaver}-%{origin}-%{version}-%{release}.%{_arch}  ### <---- NOTE
157,159c107,116
< # The suffix for file names when we have to make them unique (from
< # other Java packages).
< %global uniquesuffix          %{name}
---
> %global jredir          %{sdkdir}/jre
> %global sdkbindir       %{_jvmdir}/%{sdkdir}/bin
> %global jrebindir       %{_jvmdir}/%{jredir}/bin
> %global jvmjardir       %{_jvmjardir}/%{uniquesuffix}
> 
> %global fullversion     %{name}-%{version}-%{release}
> 
> %global uniquesuffix          %{fullversion}.%{_arch}
> #we can copy the javadoc to not arched dir, or made it not noarch
> %global uniquejavadocdir       %{fullversion}

Per suggestion from GSS I'm pulling in the comments from the support case that spawned this BZ.  Sorry for any duplicate info.

My understanding thus far is that the change was made to allow for multiple, minor versions of Java to be installed concurrently.  However, this is not possible in the RHEL 6 OpenJDK 1.8 packages:

$ rpm -q java-1.8.0-openjdk
java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64
$ sudo yum list java-1.8.0-openjdk --showduplicates
Loaded plugins: downloadonly, rhnplugin, security
This system is receiving updates from RHN Classic or RHN Satellite.
Installed Packages
java-1.8.0-openjdk.x86_64 1:1.8.0.31-1.b13.el6_6   @preprod-rhel-x86_64-server-6
Available Packages
java-1.8.0-openjdk.x86_64 1.8.0.20-3.b26.el6       preprod-rhel-x86_64-server-6
java-1.8.0-openjdk.x86_64 1.8.0.25-1.b17.el6       preprod-rhel-x86_64-server-6
java-1.8.0-openjdk.x86_64 1.8.0.25-3.b17.el6_6     preprod-rhel-x86_64-server-6
java-1.8.0-openjdk.x86_64 1:1.8.0.31-1.b13.el6_6   preprod-rhel-x86_64-server-6
java-1.8.0-openjdk.x86_64 1:1.8.0.45-28.b13.el6_6  preprod-rhel-x86_64-server-6
$ sudo yum install java-1.8.0-openjdk-1.8.0.20-3.b26.el6.x86_64
Loaded plugins: downloadonly, rhnplugin, security
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Install Process
Package matching java-1.8.0-openjdk-1.8.0.20-3.b26.el6.x86_64 already installed. Checking for update.
Nothing to do


Additionally, this requires that you know the precise version number (including release) in order to use the alternatives system to select your Java, which is very much non-desirable in the world of automation.  For example:

1.6/1.7, consistent, stays the same across patching:

alternatives --set java /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
alternatives --set java /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java

1.8, inconsistent from other Javas, changes every time there is a patch if I want to stay current:

alternatives --set java /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64/jre/bin/java

There needs to be a /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java registered with alternatives that always points to the latest installed OpenJDK 1.8.

Thinking about it in terms of automation, the 1.6.0 or 1.7.0 can be replaced with a variable, but 1.8.0 throws a wrench in things.

Created attachment 1057738 [details]
suggested patch v01

So here is the patch with hardcoded symlinks.
packages for playing are here: http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v01/

One confession: as we are speaking here about appearence in alternatives, I have used for those symlinks (jre-1.8.0-openjdk and java-1.8.0-openjd)  targets of _jvmdir/NVRA/jre/bin and _jvmdir/NVRA/bin

It is not same as 7 and 6, where they 
_jvmdir/N/jre/ and _jvmdir/N/ is used
I did so bause I have already existing macras for bin, but not for seconds. Ican fix it too if needed.

I have not attempted to install those packages on scratch, but breef looking inside says that thay have intended changes inside.

Created attachment 1058034 [details]
patch 3

update:

http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v02/

now everything (exceppt priority) should be ok.
The packages have broken link of jre-1.8.0-openjdk -> /usr/lib/jvm-exports/java-1.8.0-openjdk-1.8.0.51-3.b16.el6.x86_64-debug ( I did not declare the new lins macros exapndable...)
and forgot arch:-/

The patchshould have it fixed (but the build is just running

Created attachment 1058035 [details]
patch4

missing } in patch3

http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v04/

and related builds. Again, not yet tested, but worthy to try 9especially for Lukas)

Created attachment 1062613 [details]
patch5

builds avaiable in http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v05/

Yup. Now I have error during erase too:
/usr/lib/jvm/java-1.8.0-openjdk.x86_64/javac has not been configured as an alternative for javac
DEBUG util.py:377:  /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/java has not been configured as an alternative for java
DEBUG util.py:377:  warning: %postun(java-1.8.0-openjdk-headless-1:1.8.0.51-3.b16.el6.x86_64) scriptlet failed, exit status 2
DEBUG util.py:377:  Non-fatal POSTUN scriptlet failure in rpm package 1:java-1.8.0-openjdk-headless-1.8.0.51-3.b16.el6.x86_64

and yes, alternatives really are not removed.

(/me work in progress)

it is clearly typo :(

  --install %{_bindir}/java java %{jre_versionless_lnk %%1}/bin/java %{priority} \\
  --install %{_bindir}/javac javac %{sdk_versionless_lnk %%1}/bin/javac %{priority} \\

versus

alternatives --remove javac %{sdk_versionless_lnk %%1}/javac
alternatives --remove java %{jre_versionless_lnk %%1}/java

shouldbe of course 

alternatives --remove javac %{sdk_versionless_lnk %%1}/bin/javac
alternatives --remove java %{jre_versionless_lnk %%1}/bin/java

Created attachment 1062937 [details]
patchg6

All should be ok now.
http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v06/

Btw - change from NVRA to versionless N only fixed indirectly also  the  https://bugzilla.redhat.com/show_bug.cgi?id=1251560. But it does not mean that 1251560 stopped to be bug.

Ok.. there is one more issue.... I knew why I was so afraid of this change:

-update-alternatives --install %{_jvmdir}/jre-%{javaver}-%{origin} jre_%{javaver}_%{origin} %{_jvmdir}/%{jrelnk %%1} %{priority} \\
---slave %{_jvmjardir}/jre-%{javaver}       jre_%{javaver}_%{origin}_exports      %{jvmjardir %%1}
+#update-alternatives --install %{_jvmdir}/jre-%{javaver}-%{origin} jre_%{javaver}_%{origin} %{_jvmdir}/%{jrelnk %%1} %{priority} \\
+#--slave %{_jvmjardir}/jre-%{javaver}-%{origin}       jre_%{javaver}_%{origin}_exports      %{jvmjardir %%1}
+#removed in favor of hardcoded link rhbnz#1217177

and

-update-alternatives --install %{_jvmdir}/java-%{javaver}-%{origin} java_sdk_%{javaver}_%{origin} %{_jvmdir}/%{sdkdir %%1} %{priority} \\
---slave %{_jvmjardir}/java-%{javaver}-%{origin}       java_sdk_%{javaver}_%{origin}_exports      %{_jvmjardir}/%{sdkdir %%1}
+#update-alternatives --install %{_jvmdir}/java-%{javaver}-%{origin} java_sdk_%{javaver}_%{origin} %{_jvmdir}/%{sdkdir %%1} %{priority} \\
+#--slave %{_jvmjardir}/java-%{javaver}-%{origin}       java_sdk_%{javaver}_%{origin}_exports      %{_jvmjardir}/%{sdkdir %%1}
+#removed in favor of hardcoded link rhbnz#1217177


but  still doing
alternatives --remove jre_%{javaver}_%{origin} %{_jvmdir}/%{jrelnk %%1}
and
alternatives --remove java_sdk_%{javaver}_%{origin} %{_jvmdir}/%{sdkdir %%1}

I guess removal  is ok.. running another build

Created attachment 1062996 [details]
patch7

http://download.eng.brq.redhat.com/scratch/jvanek/1217177/v07/

no warnings.. looks finally ok...

Fixed like it:
http://pkgs.devel.redhat.com/cgit/rpms/java-1.8.0-openjdk/commit/?id=2cec25c812ba879ceb434925562bb3df7718f851 
and built:
https://brewweb.devel.redhat.com/buildinfo?buildID=452468

for rhel 6.8

I'm recommending to suggest this bugfix as Z stream update for 6.7

Hello.

There have been small change due to https://bugzilla.redhat.com/show_bug.cgi?id=1259241

I had to add arch also to 32 links.

SO now it is:
64b system:
 + 1           /usr/lib/jvm/{jre,java}-1.7.0-openjdk.x86_64/bin/java
   2           /usr/lib/jvm/{jre,java}-1.8.0-openjdk.x86_64/java

but 32 systems:

 + 1           /usr/lib/jvm/{jre,java}-1.7.0-openjdk/bin/java
   2           /usr/lib/jvm/{jre,java}-1.8.0-openjdk.i386/java


Is it still ok with everybody?

Is it just a typo that the "bin" is missing from the path for the 1.8.0 versions?

Missing /bin/ is typo. However the additional .i386 is real and necessary.

On 32 bit:
*+ 1           /usr/lib/jvm/java-1.7.0-openjdk/bin/javac
   2           /usr/lib/jvm/java-1.6.0-openjdk/bin/javac
   3           /usr/lib/jvm/java-1.8.0-openjdk.i386/bin/javac
-----------------------------------------------
*+ 1           /usr/lib/jvm/jre-1.7.0-openjdk/bin/java
   2           /usr/lib/jvm/jre-1.6.0-openjdk/bin/java
   3           /usr/lib/jvm/jre-1.8.0-openjdk.i386/bin/java


On 64 bit:
   1           /usr/lib/jvm/java-1.8.0-openjdk.x86_64/bin/javac
   2           /usr/lib/jvm/java-1.6.0-openjdk.x86_64/bin/javac
*+ 3           /usr/lib/jvm/java-1.7.0-openjdk.x86_64/bin/javac
-----------------------------------------------
   1           /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java
   2           /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java
*+ 3           /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java

My needs are only for 64-bit, so for me this is just academic, but why doesn't the 32-bit have .i386 for OpenJDK 6 and 7 when the 64-bit has .x86_64?  I guess this is akin to a "lib vs lib64" argument.

I don't have permission to see 1259241 so I can't comment further on the relationship there.

(In reply to Jason Bradley Nance from comment #52)
> Is it just a typo that the "bin" is missing from the path for the 1.8.0
> versions?

YEs it is. Luaks, ty for full print out.

(In reply to Jason Bradley Nance from comment #54)
> My needs are only for 64-bit, so for me this is just academic, but why
> doesn't the 32-bit have .i386 for OpenJDK 6 and 7 when the 64-bit has
> .x86_64?  I guess this is akin to a "lib vs lib64" argument.
> 
> I don't have permission to see 1259241 so I can't comment further on the
> relationship there.

I made it accessible.

Generally speaking, the aggressive postu scripts are removing all java-1.8.0-openjdk and jre-1.8.0-openjdk links.

So after update we were facing missing java/javac on 32b - because on 64b the link (now newly hardcoded link) was java-1.8.0-openjk.x86_64

Another solution would be recreating those links in posttrans, but it is somehtng I would like to avoid at all cost.


The fix to provide rhel-6 like names was only  for this bugzilla, so I hoped 32b inconsistency will be "academic only".  Also removal ov various ifarchs in favour of arch substitution really made package better. 

So unless somebody wil be strictly affected, I would like to keep this way.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0816.html