From maechler at stat.math.ethz.ch  Thu Jul 30 10:32:22 2009
From: maechler at stat.math.ethz.ch (Martin Maechler)
Date: Thu, 30 Jul 2009 10:32:22 +0200
Subject: [Rd] R --vanilla for install/remove/shlib(Re: R 2.8->2.9 change
	that breaks some upgrade scenarios)
In-Reply-To: <820730.16144.qm@web23106.mail.ird.yahoo.com>
References: <820730.16144.qm@web23106.mail.ird.yahoo.com>
Message-ID: <19057.23190.432051.352920@lynne.math.ethz.ch>

>>>>> "HL" == Hin-Tak Leung <hintak_leung at yahoo.co.uk>
>>>>>     on Tue, 28 Jul 2009 21:38:46 +0000 (GMT) writes:

    HL> This is the change I suggested earlier - it should just disable more of user/site customization during package installation/removal, and getting more of R 2.8-like behavior back. Attached and inlined below. 
    HL> Against svn r48897 (svn HEAD AFAIK).

hmm, too bad: that's too old.

A couple of days ago I had already changed  INSTALL  to at least
*optionally* allow to use --vanilla (just one "n": note I've changed
the subject).

But as I understand different R core members have different
views on this issue, and so for now (with a newish R-devel),
I use
-----------------------
export R_INSTALL_VANILLA=true
-----------------------

somewhere in my (sh/bash) login setup, and am happy that my old
'<pkg>-check-me' shell scripts which set R_LIBS explictly again
work (whereas the current R-devel by default uses R_LIBS from our site-wide
Rprofile equivalent which is not what I think is optimal ..).

The current experimental R_INSTALL_VANILLA behavior is still
careful to find the   user-/site- specific  .libPaths()[1]
library location for installing a package in the case that no 
library location has been specified.


I'm not sure this addresses all the problems that your patch
tried to fix,
but in any case, your patch re-installing the --vanilla behavior
unconditionally (without the .libPaths()[1] detection) was not 
suffificient.


Best regards,
Martin Maechler, ETH Zurich



[Rd] R --vanilla for install/remove/shlib(Re: R 2.8->2.9 change that breaks some upgrade scenarios)
Martin Maechler