From edd at debian.org  Fri Jun 14 22:35:36 2013
From: edd at debian.org (Dirk Eddelbuettel)
Date: Fri, 14 Jun 2013 15:35:36 -0500
Subject: [Rd] R CMD INSTALL and file permission settings
In-Reply-To: <1A628E3D-CC34-4C38-B23B-03169D3C7AD0@r-project.org>
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>
Message-ID: <20923.32408.400045.470669@max.nulle.part>


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.

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

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.

Dirk

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com



[Rd] R CMD INSTALL and file permission settings
Dirk Eddelbuettel