R help - Aug 2017 - workaround for "package building problem Centos 7 & R 3.4.1"

This is for the problem I posted about last Friday.

First, the happy part, a workaround:

$ cd ~/R/x86_64-redhat-linux-gnu-library/3.4
$ ln -sf /usr/share/R/library/* .

After that, all of the packages are found by R CMD check.  R CMD check
looks in the ~/R/x86_64-redhat-linux-gnu-library/3.4 folder for
packages, but not in "/usr/share/R/library" (for whatever reason, I do
not know yet).

Why packages are not found in /usr/share/R/library is the unsolved
mystery. I don't see any difference in configuration between Centos
and Debian. In  Centos /usr/lib64/R/etc/Renviron we have the EPEL
version of the settings that Dirk Eddelbuettel worked out with R Core
for Debian packaging way back in the beginning of, well, the century:

R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-redhat-linux-gnu-library/3.4'}
R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/local/lib/R/library:/usr/lib64/R/library:/usr/share/R/library'}

R_LIBS_SITE looks good in that file. I know (for sure) these settings
were put in as adaptation to Dirk's Debian package because I sent them
to Spot Calloway back in the early days of the EPEL package.

I've found a similar report about this in the EPEL R packaging bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=1457395

Appears there that the RPM package builds, even though the package
does not survive the check. Interesting:)

Summary of the problem:

R CMD check has unexpected .libPaths().  It does not use the
R_LIBS_SITE settings in Renviron.

The error message from R CMD check without "--as-cran" is informative,
as it plainly states that .libPaths() does not seem to include the
location where the packages are installed:

###################################
$ R CMD check kutils_1.19.tar.gz
* using log directory ?/home/pauljohn/GIT/CRMDA/kutils/package/kutils.Rcheck?
* using R version 3.4.1 (2017-06-30)
* using platform: x86_64-redhat-linux-gnu (64-bit)
* using session charset: UTF-8
* checking for file ?kutils/DESCRIPTION? ... OK
* checking extension type ... Package
* this is package ?kutils? version ?1.19?
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ?kutils? can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking ?build? directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... WARNING
Error: package or namespace load failed for ?kutils? in
loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck vI[[j]]):
 there is no package called ?openxlsx?
Execution halted

It looks like this package has a loading problem when not on .libPaths:
see the messages for details.
* checking dependencies in R code ... OK
######################################

However, I promise all of the packages are installed, in
"/usr/share/R/library".

Interactive R sessions do find the required packages, and they also
seem to be found by R programs run with R CMD BATCH and R with or
without "--vanilla".

$ R --vanilla -e ".libPaths()"

R version 3.4.1 (2017-06-30) -- "Single Candle"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-redhat-linux-gnu (64-bit)
> .libPaths()
[1] "/home/pauljohn/R/x86_64-redhat-linux-gnu-library/3.4"
[2] "/usr/lib64/R/library"
[3] "/usr/share/R/library"
>
I don't understand why the Renviron settings are found, actually, but
I'm counting my good fortune that they are.

Before I found the simple easy workaround, I went though the tedious
process of building and installing all of the packages in
~/R/x86_64-redhat-linux-gnu-library/3.4. That solves the problem as
well.  It seems possible to me that many people have packages
installed in that location anyway, so they are never bothered by the
problem in the first place.

Anyway, we have a workaround, but I don't understand what's wrong to
begin with or how to fix it the right way.

If you keep Googling, you see that this problem was experienced as
early as 2012.  It has happened to some of my personal R heroes,
actually. You know who you are :)

pj
-- 
Paul E. Johnson   http://pj.freefaculty.org
Director, Center for Research Methods and Data Analysis http://crmda.ku.edu

To write to me directly, please address me at pauljohn at ku.edu.