On Thu, Jul 06, 2017 at 11:43:22AM +0200, Johannes Ranke wrote: > Hi, > > > 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 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. > > Could the package make /usr/local/lib/R/site-library owned by a dedicated > group, e.g. rlibs, so people could just adduser $USER rlibs? I do not see why > R users should read logs, which is what the adm group was apparently made for.
It could. I need to re-read the Debian Policy on this. In the past I hesitated to create a new group _globally_ just for our one application language. I don't think Python, Ruby, ... do either. Maybe still better as a local policy? > And then, this tip could be given when install.packages() fails, in addition > to the option to create a user (but not version) specific library. Usually R > libraries are not version specific, even though in the case of R 3.0.0 and > 3.4.0 compatibility was interrupted. > > > 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. > > I also like the idea of multiuser libraries, and in general the idea is that > the most current package versions play well together, and are better then > earlier versions. If this should not be the case, this should be an > exceptional situation, which may warrant a user specific library. And users can currently get this behaviour by setting the env.var (or altering .libPaths() from their .Rprofile or or or) > So an alternative to reverting the change would be to keep your change, but > to > give better support for people that > > a) have user (and version) specific libraries that were created from within R > in the past ("do you want to create a personal library instead") Questions on install are tough. And discouraged. Also, installing user is root, we really want to ask each iser... > b) want to use personal libraries for some good reason > > via this list and maybe also via improved messages from R for the case that > install.package() fails. I like a lot of the things you suggest, but I am not sure I know a good way to get there just yet. Easiest short-term (non-)fix is the reenable the R default even if many of us do not like it. We may need it as fallback. Dirk -- Three out of two people have difficulties with fractions. _______________________________________________ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian