[R] R_LIBS var needed to be set after upgrade to R 4.2.2

[Ashim Kapoor]

Dear Sir,

Many thanks for the reply.

Best,
Ashim

On Thu, Jun 2, 2022 at 12:56 PM Martin Maechler
<maechler using stat.math.ethz.ch> wrote:
>
> >>>>> Ashim Kapoor
> >>>>>     on Wed, 1 Jun 2022 14:30:58 +0530 writes:
>
>     > Dear Sir,
>     >> > I upgraded to R 4.2.2  on Debian 10 today.
>     >>
>     >> Well, I assume you mean R 4.2.0 .. at least that one exists.
>
>     > My bad, yes I made a typo. I did mean R 4.2.0.
>
>     >> > The R shell incantation worked fine and all libraries would load but,
>     >> > I needed to point the R_LIBS variable to
>     >> > /usr/local/lib/R/site-library/ in order for the R --vanilla < myfile.R
>     >> > incantation to find the libraries.
>     >>
>     >> you mean other installed *packages*
>     >>
>     >> > May I ask, why was this ? I never needed to do this on any previous
>     >> > upgrade to R.
>     >>
>     >> Well,  for me, the     R --vanilla   form also only sees the
>     >> 29 (14 "base" + 15 "Recommended") packages that come with R.
>
>     > Has this ALWAYS been the case for you ? Even with prior versions of R ?
>
> Yes; I'm sorry this was unclear.
>
>     >> Debian (& Ubuntu etc)  have used a similar setup where the
>     >> default {R-level}  .libPaths() has contained three libraries,
>     >> via
>     >>
>     >> R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
>     >>
>     >> see
>     >>
>     >> https://cloud.r-project.org/bin/linux/debian/#pathways-to-r-packages
>     >>
>     >> also for much more.
>     >> Note (also from the above CRAN page
>     >> https://cloud.r-project.org/bin/linux/debian/
>     >> [ Remember "menu"  "Binaries" -> "Linux" -> "Debian" ]
>     >>
>     >> The good thing about the Debian (and derivatives) setup is that
>     >> it also separates (as I do) the  "packages that come with R" in
>     >> one library (= /usr/lib/R/library) from packages that are
>     >> installed differently.
>
>     > My confusion is : Earlier R --vanilla incantation was working fine,
>     > even without my intervening and
>     > adding to R_LIBS. That is why I was confused.
>
>     > My main query is : Is there anything special to R 4.2.0 which needs
>     > R_LIBS to be setup seperately?
>
> to which Jeroen Ooms answered nicely -- thank you, Jeroen!
>
>     > I was hit by this problem as well a few weeks ago. You may get a more
>     > detailed answer in r-sig-debian or from Dirk directly, but from what I
>     > understood, this is now expected behavior: indeed if you start R
>     > --vanilla then /usr/local/lib is no longer included in the library path.
>
>     > The reason is that R-core made a change in 4.2.0 to pre-set values for
>     > R_LIBS_USER and R_LIBS_SITE in Renviron [1] which would take
>     > precedence over the proper distro defaults (that include
>     > /usr/local/lib) as configured by the r-base deb/rpm packages. To
>     > mitigate the problem the r-base deb package moved the appropriate
>     > R_LIBS_USER and R_LIBS_SITE definitions into Renviron.site, which
>     > takes precedence over Renviron. However a side effect of this solution
>     > is that Renviron.site is ignored in --vanilla mode. At least this is
>     > my best understanding of the problem.
>
>     > [1] https://cran.r-project.org/doc/manuals/r-release/NEWS.html
>
> Yes, as
>
>      R --help | grep -A1 -e --vanilla | head -2
>
> has given
>
>   --vanilla             Combine --no-save, --no-restore, --no-site-file,
>                         --no-init-file and --no-environ
>
> (unchanged for many years).
>
>
> Being a Linux user of more than 25 years, I've not been much of a
> Debian-or-derivatives user in recent years (apart from setting up
> and maintaining Ubuntu LTS on my wife's computer) mainly because
> of lazyness as our IT staff helps me solve all problems with
> Fedora quickly, including lowelevel device-related ones,
> I think that Debian(+derivatives) has always been the exception
> among the Linux distros and for all the others, '--vanilla'
> really meant "vanilla" in a loose sense, i.e., "just base R".
>
> I agree that I had wanted a "vanilla+strawberry" version myself, really.
> which would be just not have the  --no-site-file  switch,
> so we could call it
>    --vanilla+site
>
> {Others may hate  "feature creep" and yet more output from
> 'R --help'  ..}
>
> Martin