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. _______________________________________________ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian