From simon.urbanek at r-project.org  Fri Jun 14 22:56:12 2013
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Fri, 14 Jun 2013 16:56:12 -0400
Subject: [Rd] R CMD INSTALL and file permission settings
In-Reply-To: <20923.32408.400045.470669@max.nulle.part>
References: <20915.23136.75704.347469@max.nulle.part>
	<20917.40985.705751.95999@stat.math.ethz.ch>
	<20923.30546.509634.752403@stat.math.ethz.ch>
	<1A628E3D-CC34-4C38-B23B-03169D3C7AD0@r-project.org>
	<20923.32408.400045.470669@max.nulle.part>
Message-ID: <046C1EB4-F22D-457F-BB2C-27D666E3418F@r-project.org>

On Jun 14, 2013, at 4:35 PM, Dirk Eddelbuettel wrote:

> 
> On 14 June 2013 at 16:17, Simon Urbanek wrote:
> | I think it would be better to have a bit more sane handling of this. The decision is rarely at the install time of the package -- e.g. did you adjust the flag for INSTALL in update.packages based on the permissions? Otherwise it fails the next time and confuses the hell out of users! Although it's certainly a step up from the previously hard-coded default, I would argue that the most desired behavior is to follow the permissions already set up. If the library is setup to be group-writable then the package should be installed group-writable. The point is that anything else makes less sense - the user can still use rm -rf and re-install it even if the package is not writable. It's just update.packages() that fails.
> 
> One could also consider respecting the umask which is ignored in the
> older behaviour, ignore in what was just committed, and ignored in what you
> suggest here.  Not exactly right either.
> 

Agreed.


> But up until right now I could not update a package a colleague installed,
> and vice versa -- unless we sudo.  
> 

But you should be able to simply removing it, and re-installing, right? (This is not to suggest it as a work-around, but rather to make sure we're taking about the same situation). 


> The patch improves on this, and the only other comment was a 'thumbs up' from
> Andreas Leha who described an elaborate workaround scheme required by the
> existing shortcoming.
> 


The implementation of the group-wrtable part of is great improvement, but my point is that this doesn't solve the update.packages() problem that triggered the fix, because the flag is ignored then:

$ bin/R CMD INSTALL --group-writable ~/develop/R/packages/base64enc_0.1-0.tar.gz 
$ ls -ld library/base64enc
drwxrwxr-x  10 urbanek  admin  340 Jun 14 16:48 library/base64enc
$ sudo -u user2 bin/R -e 'update.packages(ask=F)'
$ ls -ld library/base64enc
drwxr-xr-x  11 user2  admin  374 Jun 14 16:49 library/base64enc
$ bin/R -e 'update.packages(ask=F)'
[...]
mv: rename /Volumes/Data/Builds/R-builds/rd/library/base64enc to /Volumes/Data/Builds/R-builds/rd/library/00LOCK-base64enc/base64enc: Permission denied
Warning in file.copy(f, instdir, TRUE) :
  problem copying ./NAMESPACE to /Volumes/Data/Builds/R-builds/rd/library/base64enc/NAMESPACE: Permission denied
Warning in file.copy(f, instdir, TRUE) :
  problem copying ./NEWS to /Volumes/Data/Builds/R-builds/rd/library/base64enc/NEWS: Permission denied
Warning in file(file, ifelse(append, "a", "w")) :
  cannot open file '/Volumes/Data/Builds/R-builds/rd/library/base64enc/DESCRIPTION': Permission denied
Error in file(file, ifelse(append, "a", "w")) : 
  cannot open the connection
ERROR: installing package DESCRIPTION failed for package ?base64enc?

So, as I was suggesting to use the patch to implement a more durable solution which doesn't need an extra flag but just checks the permissions on the library. While at it, it could also consult umask and thus be a good citizen ...

Cheers,
Simon



[Rd] R CMD INSTALL and file permission settings
Simon Urbanek