[R-sig-Debian] Regarding R_LIBS_USER

[Pavel Krivitsky]

Dirk,

> Your tone does not exactly help in this discussion.

My apologies. In my original bug report, I honestly thought that the
change was unintentional.

> Briefly, I (like many other people) consider Linux and Unix to be
> multi-user systems. 

I agree, but I think that an important part of the multi-user paradigm
is to limit the ability of users to affect each other in non-explicit
ways.

>  You can argue as passionately for a default
> installation in /usr/loca/lib/R/site-library as you did against. And
> some of your arguments are just silly ("dangerous group": dude, it is
> one 'sudo addgroup r-adm' [or anotther name...]) away).

The security issue would arise if R's default configuration allowed any
user (or any user with a shell) to write to /usr/loca/lib/R/site-
library. My understanding is that that's what would need to happen in
order to make R package installation work out of the box with
R_LIBS_USER unset by default.

I guess it could be an installation-time configuration option in
Debian.

> I have used such settings (such as un-setting R_LIBS_USER or its
> predecessors) for over a decade, it just works (if you give write
> permissions). It clearly helps us at work because everybody sees by
> the default the same packages. 

I understand, and I've used a variety of settings as well. In
particular, even a decade later, I remember 2.5.0 coming out with
R_LIBS_USER and a sensible default, and things Just Working on all of a
sudden. (This was on a cluster, and during the 32- to 64-bit transition
as well, so automatically loading libraries with the right architecture
was a godsend, replacing a cumbersome workaround of my own.) Perhaps
that's why I'm so passionate.

> I have also spoken with different R
> Core members and several find the default installation below $HOME
> and
> in a versioned directory less than ideal as well.  But it ensures
> writeability. Which I cannot do easily from the package.

I appreciate that it's less than ideal, but it also seems to me that
status quo ante already fulfils the goal of encouraging the use of the
site-library: it checks if the site-library is writeable, and only if
it's not, offers to create a personal library as a fallback.

As far as I can tell, knocking out that last step doesn't help those
users who want to use the site library (since they already already know
to make it readable, so they won't even see the offer to create a
personal library), but it does hurt those users who want to use the
personal library, by requiring them to take extra steps. Is the goal
here to "nudge" users towards the site-library by making it harder to
use the personal library?

> So maybe the change was too abrupt, and I think I may revert it. I
> generally prefer for packagers like myself to not divert from
> upstream
> unless they have good reasom or are unintrusive (and eg the added
> tab-completion we have here is both).  But leaving newbies without
> installable directories is bad, as is possibly hiding existing
> installations.

Part of my concern is that this change might propagate to Debian-
derivatives like Ubuntu, hitting more naive users. 

				Best Regards,
				Pavel

P.S. Something else just occurred to me, but I don't have time to test
it at the moment: R --vanilla ignores a lot of environment settings;
which of the workarounds described still work?

 
-- 
Pavel Krivitsky
Lecturer in Statistics
National Institute of Applied Statistics Research Australia (NIASRA)
School of Mathematics and Applied Statistics | Building 39C Room 154
University of Wollongong NSW 2522 Australia
T +61 2 4221 3713
Web (NIASRA): http://niasra.uow.edu.au/index.html
Web (Personal): http://www.krivitsky.net/research
ORCID: 0000-0002-9101-3362

NOTICE: This email is intended for the addressee named and may contain
confidential information. If you are not the intended recipient, please
delete it and notify the sender. Please consider the environment before
printing this email.