Bug#866768: r-base: R does not set the default user directory.

2017-07-07 Thread Dirk Eddelbuettel
On Thu, Jul 06, 2017 at 03:37:10PM -0400, Russell Almond wrote:
> Let me add a resounding ME TOO.  This is a bug and I want it fixed.

I essentially stopped reading your mail here.  That tone gets you nowhere.

Dirk

-- 
Three out of two people have difficulties with fractions.



Bug#866768: r-base: R does not set the default user directory.

2017-07-06 Thread Dirk Eddelbuettel

Just set R_LIBS_USER below /etc, for example by removing _one_ char
from /etc/R/Renviron or by setting it in /etc/environment or any other
mean.

A more constructive discussion is happening over on r-sig-debian.

Dirk

-- 
Three out of two people have difficulties with fractions.



Bug#866768: r-base: R does not set the default user directory.

2017-07-06 Thread Russell Almond

On Sat, 1 Jul 2017 12:16:53 -0500 Dirk Eddelbuettel  wrote:


On 1 July 2017 at 11:19, Pavel N. Krivitsky wrote:
| Package: r-base
| Version: 3.4.1-1
| Severity: important
| 
| By default, when asked to install or upgrade a package as a non-root user, R

| creates a subdirectory in the home directory for such packages, and puts it at
| the front of the library path. After the upgrade, I get the following:
| 
| $ R
| 
| R version 3.4.1 (2017-06-30) -- "Single Candle"

| Copyright (C) 2017 The R Foundation for Statistical Computing
| Platform: x86_64-pc-linux-gnu (64-bit)
| 
| [SNIP]
| 
| > update.packages(ask=FALSE)

| --- Please select a CRAN mirror for use in this session ---
| Warning in install.packages(update[instlib == l, "Package"], l, contriburl =
| contriburl,  :
|   'lib = "/usr/lib/R/site-library"' is not writable
| Would you like to use a personal library instead?  (y/n) y
| Would you like to create a personal library
| NA
| to install packages into?  (y/n) y
| Error in install.packages(update[instlib == l, "Package"], l, contriburl =
| contriburl,  :
|   unable to create ‘NA’
| 
|

| For some reason, rather than creating the usual path (i.e.,
| $HOME/R/$architecture/$Rversion), the path it looks for is NA.



Let me add a resounding ME TOO.  This is a bug and I want it fixed.


Not 'some reason': the same reason we have been doing this for 15 years (!!).
Multi-user use comes first.


Obviously, the way you are thinking about multi-user is very different 
from the way I think about it.  I teach statistics, so I can imagine 
that in an R lab I want two different sets of available packages:  (a) a 
carefully vetted set of packages in a site-library, and (b) local 
packages that an individual student is experimenting with.


That is, I want the student to be able to download packages from CRAN 
and try them out, or even develop new packages herself.  The default 
mechanism works just fine for that.  The student can play with anything 
in a local directory, but can't muck with the system files.


The mechanism of auto-creating the local directory goes back farther 
than 15 years.  It may have been in core S since the time of the blue 
book.  (Most of the users at Bell Labs were also developers who wanted 
to have local copies for stuff in progress and site-libraries for stuff 
that was mature enough to share).  If not, it was one of the first 
things that Doug Martin asked Bill Dunlap to add into Splus.





R> .libPaths()
[1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"   "/usr/lib/R/library"   
R>


And you are advised to create a group-writable /usr/local/lib/R/site-library, ie

edd@bud:~$ ls -ld /usr/local/lib/R/site-library/
drwxrwsr-x 93 root adm 4096 Jun 25 15:04 /usr/local/lib/R/site-library/
edd@bud:~$ id
uid=1000(edd) gid=1000(edd) 
groups=1000(edd),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),50(staff),109(lpadmin),125(sambashare)
edd@bud:~$ 


Ie it belongs to 'adm', I am 'adm' as well and so I can write there.


That solves the problem for a single admin user, not the problem for a 
lab environment.



Should you not like this, you are free to define R_LIBS_USER, the variable I
comment-out by default for the package, and set it in one of the 'site' files
below /etc/R.



May I gently suggest that if you don't like the default behavior from 
the R Core Team, that you hack your local copy rather than propagating 
your personal preferences downstream.



Dirk
 
| 


--
Russell Almond
Associate Professor, Measurement & Statistics
Educational Psychology and Learning Systems
1114 W. Call St.
Florida State University
Tallahassee, FL 32306
ralm...@fsu.edu; alm...@acm.org
http://ralmond.net/



Bug#866768: r-base: R does not set the default user directory.

2017-07-01 Thread Pavel N. Krivitsky
Package: r-base
Version: 3.4.1-1
Severity: important

By default, when asked to install or upgrade a package as a non-root user, R
creates a subdirectory in the home directory for such packages, and puts it at
the front of the library path. After the upgrade, I get the following:

$ R

R version 3.4.1 (2017-06-30) -- "Single Candle"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

[SNIP]

> update.packages(ask=FALSE)
--- Please select a CRAN mirror for use in this session ---
Warning in install.packages(update[instlib == l, "Package"], l, contriburl =
contriburl,  :
  'lib = "/usr/lib/R/site-library"' is not writable
Would you like to use a personal library instead?  (y/n) y
Would you like to create a personal library
NA
to install packages into?  (y/n) y
Error in install.packages(update[instlib == l, "Package"], l, contriburl =
contriburl,  :
  unable to create ‘NA’


For some reason, rather than creating the usual path (i.e.,
$HOME/R/$architecture/$Rversion), the path it looks for is NA.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages r-base depends on:
ii  r-base-core3.4.1-1
ii  r-recommended  3.4.1-1

Versions of packages r-base recommends:
ii  r-base-html  3.4.1-1
ii  r-doc-html   3.4.1-1

Versions of packages r-base suggests:
ii  ess 16.10-1
pn  r-doc-info | r-doc-pdf  

-- no debconf information