Bug 1324145

Summary: R Java integration doesn't work after R is installed.
Product: [Fedora] Fedora EPEL Reporter: Mike Willis <mike.willis>
Component: RAssignee: Tom "spot" Callaway <spotrh>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: epel7   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-27 08:53:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Mike Willis 2016-04-05 15:58:19 UTC 
User-Agent:       Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build Identifier: 

After installing R, installation of the R rJava package  fails because javac cannot be found. It cannot be found because R is looking for it on a path that doesn't exist.

Having yum re-install the R-java package, or manually extracting and then running the R-java package's postinstall scriptlet, fixes the problem.

Reproducible: Always

Steps to Reproduce:
A minimal CentOS 7 install with none of the dependencies of R installed (no Java installed).

[root@foo ~]# yum install R

[root@foo ~]# grep ^JAVAC /usr/lib64/R/etc/Makeconf
JAVAC = /usr/lib/jvm/jre/../bin/javac
[root@foo ~]# ls /usr/lib/jvm/jre/../bin/javac
ls: cannot access /usr/lib/jvm/jre/../bin/javac: No such file or directory
[root@foo ~]# R
R version 3.2.3 (2015-12-10) -- "Wooden Christmas-Tree"
Copyright (C) 2015 The R Foundation for Statistical Computing
Platform: x86_64-redhat-linux-gnu (64-bit)
[ snip]
> install.packages("rJava");

Actual Results:  
Installation of rJava fails because R is looking for javac somewhere that doesn't exist.

> install.packages("rJava");
[ snip]
make[2]: /usr/lib/jvm/jre/../bin/javac: Command not found
make[2]: *** [org/rosuda/JRI/Rengine.class] Error 127
make[2]: Leaving directory `/tmp/RtmpRAtDla/R.INSTALL3e96705cda92/rJava/jri/src'
make[1]: *** [src/JRI.jar] Error 2
make[1]: Leaving directory `/tmp/RtmpRAtDla/R.INSTALL3e96705cda92/rJava/jri'
make: *** [jri] Error 2
ERROR: compilation failed for package ‘rJava’
* removing ‘/usr/lib64/R/library/rJava’

The downloaded source packages are in
‘/tmp/RtmpIPYjpM/downloaded_packages’
Updating HTML index of packages in '.Library'
Making 'packages.html' ... done
Warning message:
In install.packages("rJava") :
installation of package ‘rJava’ had non-zero exit status
>
Save workspace image? [y/n/c]: n
[root@foo ~]#











Expected Results:  
Installing R results in things being set up so that javac can be found and rJava installs.

Having yum re-install R-java fixes the problem.

[root@foo ~]# yum reinstall R-java
[root@foo ~]# grep ^JAVAC /usr/lib64/R/etc/Makeconf
JAVAC = /usr/bin/javac
[root@foo ~]# ls /usr/bin/javac
/usr/bin/javac
[root@foo ~]# R
R version 3.2.3 (2015-12-10) -- "Wooden Christmas-Tree"
Copyright (C) 2015 The R Foundation for Statistical Computing
Platform: x86_64-redhat-linux-gnu (64-bit)
[ snip]
> install.packages("rJava");
[ snip]
** building package indices
** testing if installed package can be loaded
* DONE (rJava)
Making 'packages.html' ... done

The downloaded source packages are in
	‘/tmp/RtmpGZznYE/downloaded_packages’
Updating HTML index of packages in '.Library'
Making 'packages.html' ... done
> 


Manually extracting and then running the command in the R-java package's postinstall scriptlet also fixes the problem.

I've not been able to figure out why the initial R install leaves Java installation in a broken state. Perhaps there is a clue in the output of the command in the postinstall scriptlet, but the command is suffixed with "> /dev/null 2>&1 || exit 0"


[root@foo ~]# cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core) 
[root@foo  ~]# rpm -qa | grep ^R-
R-core-devel-3.2.3-4.el7.x86_64
R-java-devel-3.2.3-4.el7.x86_64
R-core-3.2.3-4.el7.x86_64
R-java-3.2.3-4.el7.x86_64
[root@foo  ~]#
Comment 1 Mike Willis 2016-04-08 16:56:48 UTC 
I've been looking in this more and found that it's not actually reproducible exactly as I described. It is reproducible though. There is inconsistent and odd behaviour at work. 


I got R-3.2.3-4.el7.src.rpm from https://dl.fedoraproject.org/pub/epel/7/SRPMS/repoview/R.html modified the spec file to remove the "> /dev/null 2>&1 || exit 0", built my own rpms and tried installing them with none of the R dependencies already installed. In the output of the R-java postinstall scriplet I saw:



Java interpreter : /usr/lib/jvm/jre/bin/java
Java version : 1.7.0_99
Java home path : /usr/lib/jvm/jre
Java compiler : /usr/lib/jvm/jre/../bin/javac
Java headers gen.: /usr/lib/jvm/jre/../bin/javah
Java archive tool: /usr/lib/jvm/jre/../bin/jar


Then I told yum to re-install the R-java package and saw:


Java interpreter : /usr/lib/jvm/jre/bin/java
Java version : 1.8.0_77
Java home path : /usr/lib/jvm/jre
Java compiler : /bin/javac
Java headers gen.: /bin/javah
Java archive tool: /bin/jar


As you can see the first time R-java was installed Java 1.7 was used and the path for Java compiler set to something that doesn't exist. But when it was re-installed, Java 1.8 was used and the Java compiler set to /bin/javac which does exist.


Looking at the yum log I found


Apr 07 16:31:03 Installed: 1:java-1.7.0-openjdk-devel-1.7.0.99-2.6.5.0.el7_2.x86_64
Apr 07 16:31:09 Installed: 1:java-1.7.0-openjdk-headless-1.7.0.99-2.6.5.0.el7_2.x86_64
Apr 07 16:31:09 Installed: 1:java-1.7.0-openjdk-1.7.0.99-2.6.5.0.el7_2.x86_64
Apr 07 16:31:09 Installed: desktop-file-utils-0.22-1.el7.x86_64
Apr 07 16:31:09 Installed: xdg-utils-1.1.0-0.16.20120809git.el7.noarch
Apr 07 16:31:09 Installed: bzip2-devel-1.0.6-13.el7.x86_64
Apr 07 16:31:10 Installed: libusbx-1.0.15-4.el7.x86_64
Apr 07 16:31:10 Installed: ghostscript-cups-9.07-18.el7.x86_64
Apr 07 16:31:10 Installed: 1:cups-1.6.3-22.el7.x86_64
Apr 07 16:31:19 Installed: R-core-3.2.3-4.el7.x86_64
Apr 07 16:31:19 Installed: R-core-devel-3.2.3-4.el7.x86_64
Apr 07 16:31:21 Installed: R-java-devel-3.2.3-4.el7.x86_64
Apr 07 16:31:21 Installed: R-devel-3.2.3-4.el7.x86_64
Apr 07 16:31:23 Installed: R-java-3.2.3-4.el7.x86_64
Apr 07 16:31:23 Installed: R-3.2.3-4.el7.x86_64
Apr 07 16:31:28 Installed: 1:java-1.8.0-openjdk-headless-1.8.0.77-0.b03.el7_2.x86_64


So java-1.8.0 is being installed before the R packages, hence used when their postinstall scriptlets are run, then java-1.8 is being installed after the R packages.



Both java-1.7 and java1.8 packages are being installed as dependencies of R and not of anything else. I can get yum to install all the R dependencies except for the java packages leaving only the R packages and the java packages listed when I run "yum install R"


[root@foo ~]# yum install texlive-epsf texinfo-tex texinfo-tex texinfo redhat-rpm-config qpdf-libs python-lxml python-javapackages pulseaudio-libs poppler-utils perl-srpm-macros perl-libintl perl-Text-Unidecode pcsc-lite-libs pcre-devel pango mpfr lksctp-tools libxslt libvorbis libusbx libthai libstdc++-devel libsndfile libquadmath libquadmath-devel libquadmath libogg libmpc libicu-devel libgfortran liberation-mono-fonts liberation-fonts-common libasyncns libXtst libXrandr libXinerama libXi libXcursor libXcomposite libRmath-devel libRmath lapack-devel lapack javapackages-tools jasper-libs hicolor-icon-theme harfbuzz gtk2 gsm graphite2 giflib ghostscript-fonts ghostscript-cups ghostscript ghostscript zziplib zlib-devel zip xz-devel xorg-x11-proto-devel xorg-x11-fonts-Type1 xorg-x11-font-utils xdg-utils urw-fonts tzdata-java ttmkfdir tre-devel tre tk-devel tk texlive gcc-c++ bzip2-devel GConf2

then

[root@foo ~]# yum install R
[ snip ]
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
R x86_64 3.2.3-4.el7 test-epel7-centos7-x86_64 24 k
Installing for dependencies:
R-core x86_64 3.2.3-4.el7 test-epel7-centos7-x86_64 50 M
R-core-devel x86_64 3.2.3-4.el7 test-epel7-centos7-x86_64 98 k
R-devel x86_64 3.2.3-4.el7 test-epel7-centos7-x86_64 23 k
R-java x86_64 3.2.3-4.el7 test-epel7-centos7-x86_64 25 k
R-java-devel x86_64 3.2.3-4.el7 test-epel7-centos7-x86_64 24 k
java-1.7.0-openjdk
x86_64 1:1.7.0.99-2.6.5.0.el7_2 test-centos7-x86_64-updates 207 k
java-1.7.0-openjdk-devel
x86_64 1:1.7.0.99-2.6.5.0.el7_2 test-centos7-x86_64-updates 9.2 M
java-1.7.0-openjdk-headless
x86_64 1:1.7.0.99-2.6.5.0.el7_2 test-centos7-x86_64-updates 25 M
java-1.8.0-openjdk-headless
x86_64 1:1.8.0.77-0.b03.el7_2 test-centos7-x86_64-updates 31 M

Transaction Summary
================================================================================
Install 1 Package (+9 Dependent packages)

Total download size: 116 M
Installed size: 307 M
Is this ok [y/d/N]:


So for some reason the R packages are dragging in two versions of the Java headless packages as dependencies.


The R-java package lists java-headless as a dependency, no version is specified

[root@foo ~]# yum deplist R-java | grep -A10 java-headless
dependency: java-headless
provider: java-1.8.0-openjdk-headless.x86_64 1:1.8.0.77-0.b03.el7_2
provider: java-1.7.0-openjdk-headless.x86_64 1:1.7.0.99-2.6.5.0.el7_2
[root@foo ~]#



If I install R now, with all it's dependencies except Java already installed, yum installs the packages in a different order to what I'd seen before!


Running transaction
Installing : 1:java-1.8.0-openjdk-headless-1.8.0.77-0.b03.el7_2.x86_6 1/10
Installing : 1:java-1.7.0-openjdk-1.7.0.99-2.6.5.0.el7_2.x86_64 2/10
Installing : 1:java-1.7.0-openjdk-headless-1.7.0.99-2.6.5.0.el7_2.x86 3/10
Installing : R-core-3.2.3-4.el7.x86_64 4/10
Installing : R-core-devel-3.2.3-4.el7.x86_64 5/10
Installing : R-java-3.2.3-4.el7.x86_64 6/10
Installing : 1:java-1.7.0-openjdk-devel-1.7.0.99-2.6.5.0.el7_2.x86_64 7/10
Installing : R-java-devel-3.2.3-4.el7.x86_64 8/10
Installing : R-devel-3.2.3-4.el7.x86_64 9/10
Installing : R-3.2.3-4.el7.x86_64 10/10



The java-1.8 package is being installed *before* the R packages, and after install is finished and the postinstall scriptlet of R-java has set up R correctly

[root@foo ~]# grep JAVAC /usr/lib64/R/etc/Makeconf
JAVAC = /bin/javac
[root@foo ~]#



However after I made this bug report, I determined that java-1.8.0 got installed *after* the R packages. This was when R was being installed by an Ansible playbook. When trying to install R both directly via yum and via an Ansible adhoc command using the yum module I found that in both cases java-1.8.0 was installed before the R packages. Then I dug through the Ansible playbook and realised that it was installing the Development Group packages before installing R. And this led me to identifying  inconsistency behaviour in yum


Do a minimal CentOS 7 install in a virtual machine. Snapshot it.

[root@foo ~]# yum install -q -y && grep JAVAC /usr/lib64/R/etc/Makeconf


JAVAC = /bin/javac
[root@foo ~]#

So that's OK. Roll back to the snapshot and install Development Tools then R


[root@foo ~]# yum install -q -y "@Development Tools" && yum install -q -y R && grep JAVAC /usr/lib64/R/etc/Makeconf
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
JAVAC = /usr/lib/jvm/jre/../bin/javac
[root@foo ~]#

I can reproduce this discrepancy over and over. 


Another issue which I don't know if it's related to this inconsistency in package installation order:

As mentioned earlier, R-java lists java-headless as a dependency:


[root@foo ~]# yum deplist R-java | grep -A10 java-headless
dependency: java-headless
provider: java-1.8.0-openjdk-headless.x86_64 1:1.8.0.77-0.b03.el7_2
provider: java-1.7.0-openjdk-headless.x86_64 1:1.7.0.99-2.6.5.0.el7_2
[root@foo ~]#

Yet yum happily removes java-headless without mentioning that R-java depends on it:

[root@foo ~]# yum remove java-headless
[ snip ]
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
java-1.7.0-openjdk-headless
x86_64 1:1.7.0.99-2.6.5.0.el7_2 @test-centos7-x86_64-updates 91 M
java-1.8.0-openjdk-headless
x86_64 1:1.8.0.77-0.b03.el7_2 @test-centos7-x86_64-updates 102 M
Removing for dependencies:
java-1.7.0-openjdk
x86_64 1:1.7.0.99-2.6.5.0.el7_2 @test-centos7-x86_64-updates 493 k
java-1.7.0-openjdk-devel
x86_64 1:1.7.0.99-2.6.5.0.el7_2 @test-centos7-x86_64-updates 36 M

Transaction Summary
================================================================================
Remove 2 Packages (+2 Dependent packages)

Installed size: 229 M
Is this ok [y/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Erasing : 1:java-1.8.0-openjdk-headless-1.8.0.77-0.b03.el7_2.x86_64 1/4
Erasing : 1:java-1.7.0-openjdk-1.7.0.99-2.6.5.0.el7_2.x86_64 2/4
Erasing : 1:java-1.7.0-openjdk-headless-1.7.0.99-2.6.5.0.el7_2.x86_6 3/4
Erasing : 1:java-1.7.0-openjdk-devel-1.7.0.99-2.6.5.0.el7_2.x86_64 4/4
Verifying : 1:java-1.7.0-openjdk-devel-1.7.0.99-2.6.5.0.el7_2.x86_64 1/4
Verifying : 1:java-1.7.0-openjdk-headless-1.7.0.99-2.6.5.0.el7_2.x86_6 2/4
Verifying : 1:java-1.7.0-openjdk-1.7.0.99-2.6.5.0.el7_2.x86_64 3/4
Verifying : 1:java-1.8.0-openjdk-headless-1.8.0.77-0.b03.el7_2.x86_64 4/4

Removed:
java-1.7.0-openjdk-headless.x86_64 1:1.7.0.99-2.6.5.0.el7_2
java-1.8.0-openjdk-headless.x86_64 1:1.8.0.77-0.b03.el7_2

Dependency Removed:
java-1.7.0-openjdk.x86_64 1:1.7.0.99-2.6.5.0.el7_2
java-1.7.0-openjdk-devel.x86_64 1:1.7.0.99-2.6.5.0.el7_2

Complete!
[root@foo ~]# rpm -q R-java
R-java-3.2.3-4.el7.x86_64
[root@foo ~]# grep JAVAC /usr/lib64/R/etc/Makeconf
JAVAC = /bin/javac
[root@foo ~]# file /bin/javac
/bin/javac: cannot open (No such file or directory)
[root@foo ~]#

So that's no good. But apparently everything's fine, no missing dependencies

[root@foo ~]# package-cleanup --problems
Loaded plugins: fastestmirror, rhnplugin
This system is receiving updates from RHN Classic or Red Hat Satellite.
No Problems Found
[root@foo ~]#


This happens because in the R spec file java-headless is listed as "Requires(post)" not "Requires".


[admin@foo ~]$ grep Requires ~/rpmbuild/SPECS/R.spec | grep java-headless
BuildRequires: java-headless
Requires(post): java-headless
[admin@foo ~]$

The R-Java package has incomplete dependencies.



Ask yum to re-install java-headless:

[root@foo ~]# yum install java-headless
Loaded plugins: fastestmirror, rhnplugin
This system is receiving updates from RHN Classic or Red Hat Satellite.
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package java-1.8.0-openjdk-headless.x86_64 1:1.8.0.77-0.b03.el7_2 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
java-1.8.0-openjdk-headless
x86_64 1:1.8.0.77-0.b03.el7_2 test-centos7-x86_64-updates 31 M

Transaction Summary
================================================================================
Install 1 Package

Total size: 31 M
Installed size: 102 M
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : 1:java-1.8.0-openjdk-headless-1.8.0.77-0.b03.el7_2.x86_64 1/1
Verifying : 1:java-1.8.0-openjdk-headless-1.8.0.77-0.b03.el7_2.x86_64 1/1

Installed:
java-1.8.0-openjdk-headless.x86_64 1:1.8.0.77-0.b03.el7_2

Complete!
[root@foo ~]# which javac
/usr/bin/which: no javac in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
[root@foo ~]# yum reinstall -q -y R-java
[root@foo ~]# grep JAVAC /usr/lib64/R/etc/Makeconf
JAVAC =
[root@foo ~]#

So that's also bad.





I've been able to figure what some of the problem is.


When the java-1.7 packages are installed /usr/lib/jvm/jre/../bin/javac exists

[root@foo ~]# rpm -qa | grep -i ^java-
java-1.7.0-openjdk-devel-1.7.0.99-2.6.5.0.el7_2.x86_64
java-1.7.0-openjdk-1.7.0.99-2.6.5.0.el7_2.x86_64
java-1.7.0-openjdk-headless-1.7.0.99-2.6.5.0.el7_2.x86_64
[root@foo ~]# file /usr/lib/jvm/jre/../bin/javac
/usr/lib/jvm/jre/../bin/javac: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=f4e97c74e9da4c6a65c130d06928d26842f670ba, stripped
[root@foo ~]#


[root@foo ~]# file /usr/lib/jvm/jre
/usr/lib/jvm/jre: symbolic link to `/etc/alternatives/jre'
[root@foo ~]# file /etc/alternatives/jre
/etc/alternatives/jre: symbolic link to `/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.99-2.6.5.0.el7_2.x86_64/jre'
[root@foo ~]#


Now if I install java-1.8.0-openjdk-headless that changes the symlink /etc/alternatives/jre


[root@foo ~]# yum install -q -y java-1.8.0-openjdk-headless
[root@foo ~]# file /etc/alternatives/jre
/etc/alternatives/jre: symbolic link to `/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.77-0.b03.el7_2.x86_64/jre'
[root@foo ~]#

And now

[root@foo ~]# file /usr/lib/jvm/jre/../bin/javac
/usr/lib/jvm/jre/../bin/javac: cannot open (No such file or directory)
[root@foo ~]#


So when the yum is told to install R *without* the Development Group packages already installed what's happens is

1] java-1.8.0-openjdk-headless is installed
2] java-1.7 packages are installed
3] R packages are installed and set to up to look for javac at /usr/lib/jvm/jre/../bin/javac which exists

And all is well.

But when the yum is told to install R *with* the Development Group packages already installed what's happens is

1] java-1.7 packages are installed
2] R packages are installed and set to up to look for java c at /usr/lib/jvm/jre/../bin/javac which exists
3] java-1.8.0-openjdk-headless is installed which makes usr/lib/jvm/jre/../bin/javac cease to exist

And all is bad.


Now, if R-java is reinstalled after java-1.8.0-openjdk-headless has been installed, the path for javac is once again set to something that exists.

The javareconf script iterates through the directories specified in ${JAVA_PATH} and tests to see if $dir/java exists. (Line 92 of /usr/lib64/R/bin/javareconf)


A bit earlier in javareconf JAVA_PATH is set to

/usr/lib/jvm/jre:/usr/lib/jvm/jre/jre/bin:/usr/lib/jvm/jre/bin:/usr/lib/jvm/jre/../bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/usr/java/bin:/usr/jdk/bin:/usr/lib/java/bin:/usr/lib/jdk/bin:/usr/local/java/bin:/usr/local/jdk/bin:/usr/local/lib/java/bin:/usr/local/lib/jdk/bin

So when java-1.7 packages packages are installed it gets as far as /usr/lib/jvm/jre/../bin finds that /usr/lib/jvm/jre/../bin/javac exists and stops looking.

When java-1.8.0-openjdk-headless is installed /usr/lib/jvm/jre/../bin/javac doesn't exist so the loop continues until it finds /bin/javac. Although in some tests I did it settled on /usr/bin/javac



Things I think need doing to fix this bug:

1] In R spec file dependencies for R-java should read

%package java
Summary: R with Fedora provided Java Runtime Environment
Group: Applications/Engineering
Requires(post): R-core = %{version}-%{release}
%if %{with_java_headless}
Requires: java-headless
%else
Requires: java
%endif


2] In /usr/lib64/R/bin/javareconf modify line 81

JAVA_PATH=${JAVA_HOME}:${JAVA_HOME}/jre/bin:${JAVA_HOME}/bin:${JAVA_HOME}/../bin:${PATH}

to
JAVA_PATH=${JAVA_HOME}:${JAVA_HOME}/jre/bin:${PATH}

In my tests, doing that means that with java.1.7.0 packages installed but not java-1.8.0-openjdk-headless, javareconf sets the path for javac to /usr/bin/javac. Even if java-1.8.0-openjdk-headless is subsequently installed /usr/bin/javac still exists, so R's Java integration still works.




Things I still don't understand:

- Why is whether yum installs java-1.8.0-openjdk-headless before or after the R packages dependent upon what other packages are already installed? (I tried building the R rpms with java-headless specified as Requires but it this inconsistency still occurred.)

- Why is  java-1.8.0-openjdk-headless being installed as a dependency of R packages?



A script I wrote whilst investigating that let me see what javareconf actually does

[root@foo ~]# cat javareconfrun
#!/bin/bash


export R_HOME=/usr/lib64/R

export R_SHARE_DIR=/usr/share/R

# following values as taken from postinstall scriptlet of R-java rpm

export JAVA_HOME=/usr/lib/jvm/jre

export JAVA_CPPFLAGS='-I/usr/lib/jvm/java/include\ -I/usr/lib/jvm/java/include/linux'


export JAVA_LIBS='-L/usr/lib/jvm/jre/lib/amd64/server -L/usr/lib/jvm/jre/lib/amd64\ -L/usr/lib/jvm/java/lib/amd64 -L/usr/java/packages/lib/amd64\ -L/lib\ -L/usr/lib\ -ljvm'

export JAVA_LD_LIBRARY_PATH=/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib

set -x
cd /tmp
echo "set -x "> javareconf
#cat /usr/lib64/R/bin/javareconf >> javareconf
sed 's!${JAVA_HOME}/../bin:!!' /usr/lib64/R/bin/javareconf >> javareconf
chmod u+x javareconf

./javareconf
[root@foo ~]#
Comment 2 Tom "spot" Callaway 2016-04-08 19:17:02 UTC 
> Things I think need doing to fix this bug:
> 
> 1] In R spec file dependencies for R-java should read
> 
> %package java
> Summary: R with Fedora provided Java Runtime Environment
> Group: Applications/Engineering
> Requires(post): R-core = %{version}-%{release}
> %if %{with_java_headless}
> Requires: java-headless
> %else
> Requires: java
> %endif

Okay. That's pretty obviously correct.

> 2] In /usr/lib64/R/bin/javareconf modify line 81
> 
> JAVA_PATH=${JAVA_HOME}:${JAVA_HOME}/jre/bin:${JAVA_HOME}/bin:${JAVA_HOME}
> /../bin:${PATH}
> 
> to
> JAVA_PATH=${JAVA_HOME}:${JAVA_HOME}/jre/bin:${PATH}

Hmmm. This one seems less correct to me. How about

JAVA_PATH=${JAVA_HOME}:${JAVA_HOME}/jre/bin:${PATH}:${JAVA_HOME}/bin:${JAVA_HOME}/../bin

I don't have answers to your other questions, unfortunately. :/
Comment 3 Mike Willis 2016-04-09 15:54:00 UTC 
(In reply to Tom "spot" Callaway from comment #2)
> > Things I think need doing to fix this bug:
> > 
> > 1] In R spec file dependencies for R-java should read
> > 
> > %package java
> > Summary: R with Fedora provided Java Runtime Environment

> > 2] In /usr/lib64/R/bin/javareconf modify line 81
> > 
> > JAVA_PATH=${JAVA_HOME}:${JAVA_HOME}/jre/bin:${JAVA_HOME}/bin:${JAVA_HOME}
> > /../bin:${PATH}
> > 
> > to
> > JAVA_PATH=${JAVA_HOME}:${JAVA_HOME}/jre/bin:${PATH}
> 
> Hmmm. This one seems less correct to me. How about
> 
> JAVA_PATH=${JAVA_HOME}:${JAVA_HOME}/jre/bin:${PATH}:${JAVA_HOME}/bin:
> ${JAVA_HOME}/../bin

I'm not able to test right now, but I'm pretty certain that's a less good change than what I suggested because:

- It removes what's in ${PATH} from the list of directories to be checked for javac and thus working symlinks in /bin/ /usr/bin/  and similar that point to javac will not be found.

- It leaves in the directory ${JAVA_HOME}/../bin which I suggest removing because it is the one that in my tests is causing the problem of javareconf setting up configuration that contains a path for javac which is valid with java-1.7 packages are installed but becomes invalid when java-1.8.0-openjdk-headless is installed.
Comment 4 Tom "spot" Callaway 2016-04-11 14:31:12 UTC 
Well, it doesn't actually remove ${PATH}. If you look, what I did is that I put ${PATH} before ${JAVA_HOME}/../bin. This should result in it finding the binary in ${PATH} first. That path is there (presumably) for some cases of Java interpreters, and I'm hesitant to take it out. This change really ought to be done in the upstream R, as this is a significant behavior change for javareconf.

Please test it and see if that works for you, I think it should.
Comment 5 Mike Willis 2016-04-11 16:21:44 UTC 
(In reply to Tom "spot" Callaway from comment #4)
> Well, it doesn't actually remove ${PATH}. If you look, what I did is that I
> put ${PATH} before ${JAVA_HOME}/../bin.

Doh. I failed at reading, sorry about that.

> This should result in it finding the
> binary in ${PATH} first. That path is there (presumably) for some cases of
> Java interpreters, and I'm hesitant to take it out. This change really ought
> to be done in the upstream R, as this is a significant behavior change for
> javareconf.

I did wonder if this is something to be fixed upstream. Though the issue occurs because /usr/lib/jvm/jre is a symlink to  /etc/alternatives/jre, which seems like a distro thing rather than an R thing. javareconf is doing it's thing, finding javac in /usr/lib/jvm/jre/../bin/ then a script in a package that has nothing to do with R is changing what /usr/lib/jvm/jre is and breaking what javareconf has done. 


> Please test it and see if that works for you, I think it should.

I've used what you suggest in comment 2 and it seems good to me. I installed R, manually hacked /usr/lib64/R/bin/javareconf then tried removing the java packages then re-installing R-java in various orders and got desirable results. Then I rebuilt the R packages with that modification, installed "@Development Tools" , then told yum to install my R packages. It was still the case that java-1.8.0-openjdk-headless was installed after the R packages

Apr 11 17:07:26 Installed: 1:java-1.7.0-openjdk-devel-1.7.0.99-2.6.5.0.el7_2.x86_64
Apr 11 17:07:32 Installed: 1:java-1.7.0-openjdk-headless-1.7.0.99-2.6.5.0.el7_2.x86_64
Apr 11 17:07:33 Installed: 1:java-1.7.0-openjdk-1.7.0.99-2.6.5.0.el7_2.x86_64
Apr 11 17:07:33 Installed: desktop-file-utils-0.22-1.el7.x86_64
Apr 11 17:07:33 Installed: xdg-utils-1.1.0-0.16.20120809git.el7.noarch
Apr 11 17:07:33 Installed: bzip2-devel-1.0.6-13.el7.x86_64
Apr 11 17:07:33 Installed: libusbx-1.0.15-4.el7.x86_64
Apr 11 17:07:33 Installed: ghostscript-cups-9.07-18.el7.x86_64
Apr 11 17:07:34 Installed: 1:cups-1.6.3-22.el7.x86_64
Apr 11 17:07:44 Installed: R-core-3.2.3-4.el7.centos.x86_64
Apr 11 17:07:44 Installed: R-core-devel-3.2.3-4.el7.centos.x86_64
Apr 11 17:07:46 Installed: R-java-devel-3.2.3-4.el7.centos.x86_64
Apr 11 17:07:46 Installed: R-devel-3.2.3-4.el7.centos.x86_64
Apr 11 17:07:47 Installed: R-java-3.2.3-4.el7.centos.x86_64
Apr 11 17:07:47 Installed: R-3.2.3-4.el7.centos.x86_64
Apr 11 17:07:53 Installed: 1:java-1.8.0-openjdk-headless-1.8.0.77-0.b03.el7_2.x86_64

but I ended up with

[root@foo ~]# grep JAVAC /usr/lib64/R/etc/Makeconf
JAVAC = /bin/javac
[root@foo ~]# 

which is valid and I was able to install rJava from CRAN.
Comment 6 Tom "spot" Callaway 2016-05-16 19:27:25 UTC 
This should be fixed in the R 3.3.0-3 update. Please test that when it lands in testing.
Comment 7 Fedora Admin user for bugzilla script actions 2020-06-03 02:45:54 UTC 
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.
Comment 8 Mike Willis 2020-07-27 08:53:57 UTC 
The change to to this bug made by PnT Account Manager brought to my attention that it is still open. I can no longer reproduce the issue I reported so I'm closing it.