Summary:
The directory /usr/local/lib/R/site-library can be used for site-wide
multi-user installations of R.
This is even the default on Debian and Ubuntu (following a suggestion by
Kurt and Fritz a decade ago over beers -- what could be better). However,
R enforces wrong permissions on directories and files there (removing
group-write) which effectively defeats this purpose, and breaks multiuser
installation: if Tom, Dick and Harry are members of group 'r-users', each
one can install in the directory, but neither can _upgrade_ a package
installed by one of the others.
I would like to correct this.
Details:
For a while now, R CMD INSTALL dispatches installation work to the R
function tools:::.install_packages() from the file tools/install.R. The
function does a lot of hardcoded 'chmod' with constant arguments:
edd at max:~/svn/r-devel/src/library/tools/R$ grep Sys.chmod install.R
if (!WINDOWS) Sys.chmod(file.path(dest, files), "755")
Sys.chmod(file.path(instdir, f), "644")
Sys.chmod(Sys.glob(file.path(instdir, "data", "*")), "644")
Sys.chmod(Sys.glob(file.path(instdir, "demo", "*")), "644")
Sys.chmod(Sys.glob(file.path(instdir, "exec", "*")), "755")
Sys.chmod(i2_files[execs], "755")
edd at max:~/svn/r-devel/src/library/tools/R$
Moreover, it also calls a C function for cleanup cleanup:
edd at max:~/svn/r-devel/src/library/tools/R$ grep ".Call(dir" install.R
.Call(dirchmod, instdir)
.Call(dirchmod, ss)
.Call(dirchmod, ss)
## tree, since the later .Call(dirchmod) call will
edd at max:~/svn/r-devel/src/library/tools/R$
which also uses unconditional 644 / 755
mode_t mask = S_IRUSR | S_IRGRP | S_IROTH | S_IWUSR, /* 0644 */
dirmask = mask | S_IXUSR | S_IXGRP | S_IXOTH; /* 0755 */
Proposal:
Add a new option() [with a to-be-determined name] which, if enabled, turns
on group-write modes for files and directories, ie "664" and "775".
One way would be to set two character vars at the beginning of
_install_packages and to pass a flag to the dirchmod call as so that
'S_IWGRP' (the 00020 "write by group" permission) can be set.
I would be happy to write such a patch (including documentation updates) if
someone from R Core can signal willigness to look at it.
Thanks, Dirk
Hi all,
Dirk Eddelbuettel <edd at debian.org> writes:
Summary:
The directory /usr/local/lib/R/site-library can be used for site-wide
multi-user installations of R.
This is even the default on Debian and Ubuntu (following a suggestion by
Kurt and Fritz a decade ago over beers -- what could be better). However,
R enforces wrong permissions on directories and files there (removing
group-write) which effectively defeats this purpose, and breaks multiuser
installation: if Tom, Dick and Harry are members of group 'r-users', each
one can install in the directory, but neither can _upgrade_ a package
installed by one of the others.
I would like to correct this.
This is just a message from a user who would greatly appreciate such a
change. We have written a script based on inotify to correct that group
writing permissions which we would gladly dismiss again.
Best,
Andreas
Dirk Eddelbuettel <edd at debian.org>
on Sat, 8 Jun 2013 11:22:56 -0500 writes:
> Summary:
> The directory /usr/local/lib/R/site-library can be used for site-wide
> multi-user installations of R.
> This is even the default on Debian and Ubuntu (following a suggestion by
> Kurt and Fritz a decade ago over beers -- what could be better). However,
> R enforces wrong permissions on directories and files there (removing
> group-write) which effectively defeats this purpose, and breaks multiuser
> installation: if Tom, Dick and Harry are members of group 'r-users', each
> one can install in the directory, but neither can _upgrade_ a package
> installed by one of the others.
> I would like to correct this.
> Details:
[..........]
> Proposal:
> Add a new option() [with a to-be-determined name] which, if enabled, turns
> on group-write modes for files and directories, ie "664" and "775".
[.........]
> I would be happy to write such a patch (including documentation updates) if
> someone from R Core can signal willigness to look at it.
"signal!"
:-)
Regards,
Martin
Martin Maechler <maechler at stat.math.ethz.ch>
on Mon, 10 Jun 2013 11:44:57 +0200 writes:
Dirk Eddelbuettel <edd at debian.org>
on Sat, 8 Jun 2013 11:22:56 -0500 writes:
>> Summary:
>> The directory /usr/local/lib/R/site-library can be used
>> for site-wide multi-user installations of R.
>> This is even the default on Debian and Ubuntu (following
>> a suggestion by Kurt and Fritz a decade ago over beers --
>> what could be better). However, R enforces wrong
>> permissions on directories and files there (removing
>> group-write) which effectively defeats this purpose, and
>> breaks multiuser installation: if Tom, Dick and Harry are
>> members of group 'r-users', each one can install in the
>> directory, but neither can _upgrade_ a package installed
>> by one of the others.
>> I would like to correct this.
>> Details:
> [..........]
>> Proposal:
>> Add a new option() [with a to-be-determined name] which,
>> if enabled, turns on group-write modes for files and
>> directories, ie "664" and "775".
> [.........]
>> I would be happy to write such a patch (including
>> documentation updates) if someone from R Core can signal
>> willigness to look at it.
> "signal!" :-)
In the mean time, Dirk has sent me a patch which I've Martinized
a tiny bit,
and committed now, both for R-devel and 'R 3.0.1 patched'.
The new feature is advertized as
R CMD INSTALL --group-writable installs packages group writably,
such that update.packages() works for other group members
(suggested and from a patch by Dirk Eddelbuettel).
Wishing everyone a nice weekend,
Martin Maechler,
ETH Zurich
On Jun 14, 2013, at 4:04 PM, Martin Maechler wrote:
Martin Maechler <maechler at stat.math.ethz.ch>
on Mon, 10 Jun 2013 11:44:57 +0200 writes:
Dirk Eddelbuettel <edd at debian.org>
on Sat, 8 Jun 2013 11:22:56 -0500 writes:
Summary:
The directory /usr/local/lib/R/site-library can be used
for site-wide multi-user installations of R.
This is even the default on Debian and Ubuntu (following
a suggestion by Kurt and Fritz a decade ago over beers --
what could be better). However, R enforces wrong
permissions on directories and files there (removing
group-write) which effectively defeats this purpose, and
breaks multiuser installation: if Tom, Dick and Harry are
members of group 'r-users', each one can install in the
directory, but neither can _upgrade_ a package installed
by one of the others.
I would like to correct this.
Details:
[..........]
Proposal:
Add a new option() [with a to-be-determined name] which,
if enabled, turns on group-write modes for files and
directories, ie "664" and "775".
[.........]
I would be happy to write such a patch (including
documentation updates) if someone from R Core can signal
willigness to look at it.
"signal!" :-)
In the mean time, Dirk has sent me a patch which I've Martinized
a tiny bit,
and committed now, both for R-devel and 'R 3.0.1 patched'.
The new feature is advertized as
R CMD INSTALL --group-writable installs packages group writably,
such that update.packages() works for other group members
(suggested and from a patch by Dirk Eddelbuettel).
Wishing everyone a nice weekend,
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.
Cheers,
Simon
| 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
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
Simon Urbanek <simon.urbanek at r-project.org> writes:
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).
I am not sure I understand this correctly. But I don't see how 'rm -rf'
would be possible without sudo:
$ ls -l /usr/local/lib/R/site-library/ | tail -n 1
drwxr-xr-x 12 aleha staff 4096 Apr 7 2012 XML
Here, the user aleha installed XML into /usr/local/lib/R/site-library and
no other user (not even in the same group) has write access to that
package's directory. So, neither update nor removal is possible. Am I
missing the point?
[...]
Regards,
Andreas
| On Jun 14, 2013, at 4:35 PM, Dirk Eddelbuettel wrote:
| > 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).
I think not:
-- 'Alice' and 'Bob' are both members of 'r-users'.
-- Alice installs, it becomes '644' / '755' owned by 'alice:r-users'.
-- Bob tries to update (or remove, as you suggest)
-- Bob has no group-write (despite sharing the group) or world-write rights
-- Hence this fails
-- My patch (reworked by Martin) fixes precisely this
| 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
Mode 775, good.
| $ 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
Mode 755 -- why?
| $ 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?
I will admit to having written and tested the patch at home, under single
user, not work. But at work I "simulated" the exact same situation by doing
repeated 'sudo chmod -R g+w /usr/local/lib/R/site-library' after which 'Bob'
can indeed updated packages installed by 'Alice'.
Which is the whole point.
| 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 ...
We can always refine, but I still think that we're better off with the patch
than before.
Dirk
Dirk Eddelbuettel <edd at debian.org>
on Fri, 14 Jun 2013 22:27:32 -0500 writes:
> On 14 June 2013 at 16:56, Simon Urbanek wrote: | On Jun
> 14, 2013, at 4:35 PM, Dirk Eddelbuettel wrote: | > 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).
> I think not:
> -- 'Alice' and 'Bob' are both members of 'r-users'.
> -- Alice installs, it becomes '644' / '755' owned by
> 'alice:r-users'.
> -- Bob tries to update (or remove, as you suggest)
> -- Bob has no group-write (despite sharing the group) or
> world-write rights
> -- Hence this fails
> -- My patch (reworked by Martin) fixes precisely this
> | 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
> Mode 775, good.
> | $ 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
> Mode 755 -- why?
because update.packages calling install.packages() does not
preserve the group-writability.
I think this was the most important point by Simon, and I agree
that we should further improve the current R-devel (it *is*
in ongoing development, so all is fine).
> | $ 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?
> I will admit to having written and tested the patch at
> home, under single user, not work. But at work I
> "simulated" the exact same situation by doing repeated
> 'sudo chmod -R g+w /usr/local/lib/R/site-library' after
> which 'Bob' can indeed updated packages installed by
> 'Alice'.
> Which is the whole point.
well, modulo the update.packages() example above ,..
> | 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 ...
> We can always refine, but I still think that we're better
> off with the patch than before.
> Dirk
> --
> Dirk Eddelbuettel | edd at debian.org |
I think we could agree that we basically all agree, at least
with these two
1) The current R-devel code, basically Dirk's patches, is an
improvement to the previous situation.
2) It needs to be further tweaked and improved in order to
"coexist" nicely with update.packages(), install.packages().
The question really is, and I understand that's Simon's Q,
if there is a solution to this problem which makes the use of
'--group-writable' almost (or completely?) superfluous.
IIUC, Simon proposes that the *library* directory (aka
'lib.loc')'s group permissions should be determinant for the
package's group permissions in all(?) cases.
notably when the library is group writable, packages should all
be installed (and hence also updated) group writably in any case.
I tend to agree with Simon on this proposal.
The other issue is "respecting" the umask.
Here, I'm much less sure what we want.
Many organizations have quite rigid umask defaults, also in my
experience, about 2-5% of the users are relatively paranoid and
learn to set their own umasks quite restrictively.
So, if these are "part of our group", and if they update a
package in our group-writable library, should their paranoid
umask setting really be taken for the newly installed package?
My vote would be "no"...
and I more and more tend to think that a simple scheme such as
(I think Simon proposed) to simply install packages
"all group writable" in a group-writable directory would be
entirely sufficient.
Comments?
Martin
On Jun 14, 2013, at 11:27 PM, Dirk Eddelbuettel wrote:
On 14 June 2013 at 16:56, Simon Urbanek wrote:
| On Jun 14, 2013, at 4:35 PM, Dirk Eddelbuettel wrote:
| > 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).
I think not:
-- 'Alice' and 'Bob' are both members of 'r-users'.
-- Alice installs, it becomes '644' / '755' owned by 'alice:r-users'.
-- Bob tries to update (or remove, as you suggest)
-- Bob has no group-write (despite sharing the group) or world-write rights
-- Hence this fails
Nope this is wrong. If you have write rights on a directory, you can delete files even if you don't have write rights on them. That's why rf -rf + re-install works but update doesn't.
-- My patch (reworked by Martin) fixes precisely this
| 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
Mode 775, good.
| $ 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
Mode 755 -- why?
Because update.packages() doesn't restore the group-writable bit. Which leads us to my point that this is not what you really want.
| $ 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?
I will admit to having written and tested the patch at home, under single
user, not work. But at work I "simulated" the exact same situation by doing
repeated 'sudo chmod -R g+w /usr/local/lib/R/site-library' after which 'Bob'
can indeed updated packages installed by 'Alice'.
Which is the whole point.
| 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 ...
We can always refine, but I still think that we're better off with the patch
than before.
I wasn't disputing the fact that it's great to have group-writable bit under control, but adding the flag to INSTALL doesn't solve the problem - and as you saw the result is a bit misleading in the context that it was discussed and thus may cause more confusion. I am arguing that the solution would be to (at least as default) take the directory writable bit because that is really what decides things anyway. You had a good point of also combining it with umask.
Cheers,
Simon
| Because update.packages() doesn't restore the group-writable bit. Which leads us to my point that this is not what you really want.
Ooops. I'll take another look.
My initial patch to Martin did not have the argument to install, but simply a
fixed use of "664" and "775" modes if and only if an option() was set. We
seem to need that in update.packages() too.
| I wasn't disputing the fact that it's great to have group-writable bit
| under control, but adding the flag to INSTALL doesn't solve the problem -
| and as you saw the result is a bit misleading in the context that it was
| discussed and thus may cause more confusion. I am arguing that the solution
| would be to (at least as default) take the directory writable bit because
| that is really what decides things anyway. You had a good point of also
| combining it with umask.
Re umask: Users get that wrong too often too.
I think I'd prefer to add another patch to update.packages().
Dirk
On 15 June 2013 at 07:00, Dirk Eddelbuettel wrote:
|
| On 15 June 2013 at 07:47, Simon Urbanek wrote:
| | Because update.packages() doesn't restore the group-writable bit. Which leads us to my point that this is not what you really want.
|
| Ooops. I'll take another look.
Done. "It works." For fairly generous definitions of working. I'll detail:
i) My initial patch only used options() to set things. Martin was not to
enthralled with this and guided the patch towards using --group-writable
as an option.
ii) With --group-writable, installation works but updates fail as noticed by
Simon.
iii) If we fall back to using options() [ or an environment variable ],
things works. A log is below.
iv) I guess those of you who want the --group-writeable option need to ensure
it also works for update.packages() as new option?
I am happy with what we have right now as it works in the context established
by my patch. Martin's addition of --group-writable is a bit more ambitious
and we may need to enhance update.package(), or tell everybody to also (??)
use the option() setting, or environment variable.
Two things follow, a quick test script and a log from the script.
Dirk
Script
#!/bin/bash
## we use digest as an example as it is pretty small
cd ~/svn/digest
ls -l digest_0.6.?.tar.gz
## we make two assumptions:
##
## a) R-devel (called via a shell script wrapper)
~/bin/R-devel.sh --version | head -1
##
## b) An option has been set
cat /usr/local/lib/R-devel/lib/R/etc/Rprofile.site
## now install an older version so that we can upgrade later
## this is running as 'edd' ie me
~/bin/R-devel.sh CMD INSTALL digest_0.6.2.tar.gz
ls -ld /usr/local/lib/R/site-library/digest/
ls -lR /usr/local/lib/R/site-library/digest/
## now try the upgrade as another user in the group
sudo su lmp -c '~edd/bin/R-devel.sh -e "update.packages(repos=\"http://cran.r-project.org\", ask=FALSE, lib.loc=\"/usr/local/lib/R/site-library\")"'
ls -ld /usr/local/lib/R/site-library/digest/
ls -lR /usr/local/lib/R/site-library/digest/
Session log
edd at max:~$ /tmp/testRupgrade.sh
-rw-r--r-- 1 edd edd 53344 Nov 25 2012 digest_0.6.0.tar.gz
-rw-r--r-- 1 edd edd 76839 Jan 21 09:25 digest_0.6.1.tar.gz
-rw-r--r-- 1 edd edd 76771 Jan 25 11:33 digest_0.6.2.tar.gz
-rw-r--r-- 1 edd edd 78002 Feb 16 06:35 digest_0.6.3.tar.gz
R Under development (unstable) (2013-06-14 r62964) -- "Unsuffered Consequences"
options("group.writable.pkgs"=TRUE)
* installing to library ?/usr/local/lib/R/site-library?
* installing *source* package ?digest? ...
** libs
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c aes.c -o aes.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c crc32.c -o crc32.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c digest.c -o digest.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c md5.c -o md5.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c raes.c -o raes.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c sha1.c -o sha1.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c sha2.c -o sha2.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c sha256.c -o sha256.o
sha2.c: In function ?SHA256_Final?:
sha2.c:606:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
sha2.c: In function ?SHA512_Last?:
sha2.c:923:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
sha2.c:924:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
ccache gcc-4.7 -shared -L/usr/local/lib -o digest.so aes.o crc32.o digest.o md5.o raes.o sha1.o sha2.o sha256.o -L/usr/local/lib/R-devel/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/digest/libs
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (digest)
drwxrwxr-x 7 edd staff 4096 Jun 15 10:42 /usr/local/lib/R/site-library/digest/
/usr/local/lib/R/site-library/digest/:
total 52
-rw-rw-r-- 1 edd staff 1605 Jun 15 10:42 DESCRIPTION
-rw-rw-r-- 1 edd staff 18092 Jun 15 10:42 GPL-2
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 help
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 html
-rw-rw-r-- 1 edd staff 271 Jun 15 10:42 INDEX
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 libs
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 Meta
-rw-rw-r-- 1 edd staff 140 Jun 15 10:42 NAMESPACE
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 R
/usr/local/lib/R/site-library/digest/help:
total 36
-rw-rw-r-- 1 edd staff 80 Jun 15 10:42 aliases.rds
-rw-rw-r-- 1 edd staff 32 Jun 15 10:42 AnIndex
-rw-rw-r-- 1 edd staff 17857 Jun 15 10:42 digest.rdb
-rw-rw-r-- 1 edd staff 193 Jun 15 10:42 digest.rdx
-rw-rw-r-- 1 edd staff 140 Jun 15 10:42 paths.rds
/usr/local/lib/R/site-library/digest/html:
total 8
-rw-rw-r-- 1 edd staff 1236 Jun 15 10:42 00Index.html
-rw-rw-r-- 1 edd staff 1179 Jun 15 10:42 R.css
/usr/local/lib/R/site-library/digest/libs:
total 120
-rwxrwxr-x 1 edd staff 118956 Jun 15 10:42 digest.so
/usr/local/lib/R/site-library/digest/Meta:
total 20
-rw-rw-r-- 1 edd staff 351 Jun 15 10:42 hsearch.rds
-rw-rw-r-- 1 edd staff 117 Jun 15 10:42 links.rds
-rw-rw-r-- 1 edd staff 224 Jun 15 10:42 nsInfo.rds
-rw-rw-r-- 1 edd staff 1271 Jun 15 10:42 package.rds
-rw-rw-r-- 1 edd staff 331 Jun 15 10:42 Rd.rds
/usr/local/lib/R/site-library/digest/R:
total 16
-rw-rw-r-- 1 edd staff 1056 Jun 15 10:42 digest
-rw-rw-r-- 1 edd staff 4168 Jun 15 10:42 digest.rdb
-rw-rw-r-- 1 edd staff 388 Jun 15 10:42 digest.rdx
R Under development (unstable) (2013-06-14 r62964) -- "Unsuffered Consequences"
Copyright (C) 2013 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
Dirk Eddelbuettel <edd at debian.org>
on Sat, 15 Jun 2013 10:45:04 -0500 writes:
> On 15 June 2013 at 07:00, Dirk Eddelbuettel wrote:
> |
> | On 15 June 2013 at 07:47, Simon Urbanek wrote: | |
> Because update.packages() doesn't restore the
> group-writable bit. Which leads us to my point that this
> is not what you really want.
> |
> | Ooops. I'll take another look.
> Done. "It works." For fairly generous definitions of
> working. I'll detail:
> i) My initial patch only used options() to set things.
> Martin was not to enthralled with this and guided the
> patch towards using --group-writable as an option.
> ii) With --group-writable, installation works but updates
> fail as noticed by Simon.
> iii) If we fall back to using options() [ or an
> environment variable ], things works. A log is below.
Hmm, but this only works if everyone who calls update.packages() also has
this options() setting, no?
Why would the update keep the package files group writable otherwise ?
If the updater has no group-writable option she can still update
the package you installed, but you can no longer, right?
I still think the approach to abolish all settings and just
trigger group-writable package installation *when* the library
directory is group writable is so simple we should adopt it,
and can forget all options/ command line arguments / environment
variables about this topic.
Martin
> iv) I guess those of you who want the --group-writeable
> option need to ensure it also works for update.packages()
> as new option?
> I am happy with what we have right now as it works in the
> context established by my patch. Martin's addition of
> --group-writable is a bit more ambitious and we may need
> to enhance update.package(), or tell everybody to also
> (??) use the option() setting, or environment variable.
> Two things follow, a quick test script and a log from the
> script.
> Dirk
Script
#!/bin/bash
## we use digest as an example as it is pretty small
cd ~/svn/digest
ls -l digest_0.6.?.tar.gz
## we make two assumptions:
##
## a) R-devel (called via a shell script wrapper)
~/bin/R-devel.sh --version | head -1
##
## b) An option has been set
cat /usr/local/lib/R-devel/lib/R/etc/Rprofile.site
## now install an older version so that we can upgrade later
## this is running as 'edd' ie me
~/bin/R-devel.sh CMD INSTALL digest_0.6.2.tar.gz
ls -ld /usr/local/lib/R/site-library/digest/
ls -lR /usr/local/lib/R/site-library/digest/
## now try the upgrade as another user in the group
sudo su lmp -c '~edd/bin/R-devel.sh -e "update.packages(repos=\"http://cran.r-project.org\", ask=FALSE, lib.loc=\"/usr/local/lib/R/site-library\")"'
ls -ld /usr/local/lib/R/site-library/digest/
ls -lR /usr/local/lib/R/site-library/digest/
Session log
edd at max:~$ /tmp/testRupgrade.sh
-rw-r--r-- 1 edd edd 53344 Nov 25 2012 digest_0.6.0.tar.gz
-rw-r--r-- 1 edd edd 76839 Jan 21 09:25 digest_0.6.1.tar.gz
-rw-r--r-- 1 edd edd 76771 Jan 25 11:33 digest_0.6.2.tar.gz
-rw-r--r-- 1 edd edd 78002 Feb 16 06:35 digest_0.6.3.tar.gz
R Under development (unstable) (2013-06-14 r62964) -- "Unsuffered Consequences"
options("group.writable.pkgs"=TRUE)
* installing to library ?/usr/local/lib/R/site-library?
* installing *source* package ?digest? ...
** libs
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c aes.c -o aes.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c crc32.c -o crc32.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c digest.c -o digest.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c md5.c -o md5.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c raes.c -o raes.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c sha1.c -o sha1.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c sha2.c -o sha2.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c sha256.c -o sha256.o
sha2.c: In function ?SHA256_Final?:
sha2.c:606:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
sha2.c: In function ?SHA512_Last?:
sha2.c:923:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
sha2.c:924:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
ccache gcc-4.7 -shared -L/usr/local/lib -o digest.so aes.o crc32.o digest.o md5.o raes.o sha1.o sha2.o sha256.o -L/usr/local/lib/R-devel/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/digest/libs
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (digest)
drwxrwxr-x 7 edd staff 4096 Jun 15 10:42 /usr/local/lib/R/site-library/digest/
/usr/local/lib/R/site-library/digest/:
total 52
-rw-rw-r-- 1 edd staff 1605 Jun 15 10:42 DESCRIPTION
-rw-rw-r-- 1 edd staff 18092 Jun 15 10:42 GPL-2
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 help
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 html
-rw-rw-r-- 1 edd staff 271 Jun 15 10:42 INDEX
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 libs
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 Meta
-rw-rw-r-- 1 edd staff 140 Jun 15 10:42 NAMESPACE
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 R
/usr/local/lib/R/site-library/digest/help:
total 36
-rw-rw-r-- 1 edd staff 80 Jun 15 10:42 aliases.rds
-rw-rw-r-- 1 edd staff 32 Jun 15 10:42 AnIndex
-rw-rw-r-- 1 edd staff 17857 Jun 15 10:42 digest.rdb
-rw-rw-r-- 1 edd staff 193 Jun 15 10:42 digest.rdx
-rw-rw-r-- 1 edd staff 140 Jun 15 10:42 paths.rds
/usr/local/lib/R/site-library/digest/html:
total 8
-rw-rw-r-- 1 edd staff 1236 Jun 15 10:42 00Index.html
-rw-rw-r-- 1 edd staff 1179 Jun 15 10:42 R.css
/usr/local/lib/R/site-library/digest/libs:
total 120
-rwxrwxr-x 1 edd staff 118956 Jun 15 10:42 digest.so
/usr/local/lib/R/site-library/digest/Meta:
total 20
-rw-rw-r-- 1 edd staff 351 Jun 15 10:42 hsearch.rds
-rw-rw-r-- 1 edd staff 117 Jun 15 10:42 links.rds
-rw-rw-r-- 1 edd staff 224 Jun 15 10:42 nsInfo.rds
-rw-rw-r-- 1 edd staff 1271 Jun 15 10:42 package.rds
-rw-rw-r-- 1 edd staff 331 Jun 15 10:42 Rd.rds
/usr/local/lib/R/site-library/digest/R:
total 16
-rw-rw-r-- 1 edd staff 1056 Jun 15 10:42 digest
-rw-rw-r-- 1 edd staff 4168 Jun 15 10:42 digest.rdb
-rw-rw-r-- 1 edd staff 388 Jun 15 10:42 digest.rdx
R Under development (unstable) (2013-06-14 r62964) -- "Unsuffered Consequences"
Copyright (C) 2013 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
| >>>>> Dirk Eddelbuettel <edd at debian.org>
| >>>>> on Sat, 15 Jun 2013 10:45:04 -0500 writes:
|
| > On 15 June 2013 at 07:00, Dirk Eddelbuettel wrote:
| > |
| > | On 15 June 2013 at 07:47, Simon Urbanek wrote: | |
| > Because update.packages() doesn't restore the
| > group-writable bit. Which leads us to my point that this
| > is not what you really want.
| > |
| > | Ooops. I'll take another look.
|
| > Done. "It works." For fairly generous definitions of
| > working. I'll detail:
|
| > i) My initial patch only used options() to set things.
| > Martin was not to enthralled with this and guided the
| > patch towards using --group-writable as an option.
|
| > ii) With --group-writable, installation works but updates
| > fail as noticed by Simon.
|
| > iii) If we fall back to using options() [ or an
| > environment variable ], things works. A log is below.
|
| Hmm, but this only works if everyone who calls update.packages() also has
| this options() setting, no?
Exactly, which is why I like options() called from $R_HOME/etc/Rprofile.site
for all users. Just how I add all (relevant) users to the relevant group.
This is meant for site-wide policy and site-wide once-and-for-all behaviour,
not having to tell all luser to please add --group-writable to their
invocations. Because they will forget.
| Why would the update keep the package files group writable otherwise ?
Because we tell it to via options().
| I still think the approach to abolish all settings and just
| trigger group-writable package installation *when* the library
| directory is group writable is so simple we should adopt it,
| and can forget all options/ command line arguments / environment
| variables about this topic.
Maybe. I guess you would still need to match the gid for which the directory
is set to the gid of the user running the update.
Or you just use what we now and let the operating system handle this. It is
pretty good at it :)
Dirk
On Jun 15, 2013, at 2:42 PM, Martin Maechler wrote:
Dirk Eddelbuettel <edd at debian.org>
on Sat, 15 Jun 2013 10:45:04 -0500 writes:
On 15 June 2013 at 07:00, Dirk Eddelbuettel wrote:
|
| On 15 June 2013 at 07:47, Simon Urbanek wrote: | |
Because update.packages() doesn't restore the
group-writable bit. Which leads us to my point that this
is not what you really want.
|
| Ooops. I'll take another look.
Done. "It works." For fairly generous definitions of
working. I'll detail:
i) My initial patch only used options() to set things.
Martin was not to enthralled with this and guided the
patch towards using --group-writable as an option.
ii) With --group-writable, installation works but updates
fail as noticed by Simon.
iii) If we fall back to using options() [ or an
environment variable ], things works. A log is below.
Hmm, but this only works if everyone who calls update.packages() also has
this options() setting, no?
Why would the update keep the package files group writable otherwise ?
If the updater has no group-writable option she can still update
the package you installed, but you can no longer, right?
I still think the approach to abolish all settings and just
trigger group-writable package installation *when* the library
directory is group writable is so simple we should adopt it,
and can forget all options/ command line arguments / environment
variables about this topic.
I fully agree. Also thanks for summarizing the discussion earlier today - it was dead on.
Thanks,
Simon
Martin
iv) I guess those of you who want the --group-writeable
option need to ensure it also works for update.packages()
as new option?
I am happy with what we have right now as it works in the
context established by my patch. Martin's addition of
--group-writable is a bit more ambitious and we may need
to enhance update.package(), or tell everybody to also
(??) use the option() setting, or environment variable.
Two things follow, a quick test script and a log from the
script.
Dirk
Script
#!/bin/bash
## we use digest as an example as it is pretty small
cd ~/svn/digest
ls -l digest_0.6.?.tar.gz
## we make two assumptions:
##
## a) R-devel (called via a shell script wrapper)
~/bin/R-devel.sh --version | head -1
##
## b) An option has been set
cat /usr/local/lib/R-devel/lib/R/etc/Rprofile.site
## now install an older version so that we can upgrade later
## this is running as 'edd' ie me
~/bin/R-devel.sh CMD INSTALL digest_0.6.2.tar.gz
ls -ld /usr/local/lib/R/site-library/digest/
ls -lR /usr/local/lib/R/site-library/digest/
## now try the upgrade as another user in the group
sudo su lmp -c '~edd/bin/R-devel.sh -e "update.packages(repos=\"http://cran.r-project.org\", ask=FALSE, lib.loc=\"/usr/local/lib/R/site-library\")"'
ls -ld /usr/local/lib/R/site-library/digest/
ls -lR /usr/local/lib/R/site-library/digest/
Session log
edd at max:~$ /tmp/testRupgrade.sh
-rw-r--r-- 1 edd edd 53344 Nov 25 2012 digest_0.6.0.tar.gz
-rw-r--r-- 1 edd edd 76839 Jan 21 09:25 digest_0.6.1.tar.gz
-rw-r--r-- 1 edd edd 76771 Jan 25 11:33 digest_0.6.2.tar.gz
-rw-r--r-- 1 edd edd 78002 Feb 16 06:35 digest_0.6.3.tar.gz
R Under development (unstable) (2013-06-14 r62964) -- "Unsuffered Consequences"
options("group.writable.pkgs"=TRUE)
* installing to library ?/usr/local/lib/R/site-library?
* installing *source* package ?digest? ...
** libs
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c aes.c -o aes.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c crc32.c -o crc32.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c digest.c -o digest.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c md5.c -o md5.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c raes.c -o raes.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c sha1.c -o sha1.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c sha2.c -o sha2.o
ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG -I/usr/local/include -fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c sha256.c -o sha256.o
sha2.c: In function ?SHA256_Final?:
sha2.c:606:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
sha2.c: In function ?SHA512_Last?:
sha2.c:923:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
sha2.c:924:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
ccache gcc-4.7 -shared -L/usr/local/lib -o digest.so aes.o crc32.o digest.o md5.o raes.o sha1.o sha2.o sha256.o -L/usr/local/lib/R-devel/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/digest/libs
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (digest)
drwxrwxr-x 7 edd staff 4096 Jun 15 10:42 /usr/local/lib/R/site-library/digest/
/usr/local/lib/R/site-library/digest/:
total 52
-rw-rw-r-- 1 edd staff 1605 Jun 15 10:42 DESCRIPTION
-rw-rw-r-- 1 edd staff 18092 Jun 15 10:42 GPL-2
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 help
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 html
-rw-rw-r-- 1 edd staff 271 Jun 15 10:42 INDEX
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 libs
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 Meta
-rw-rw-r-- 1 edd staff 140 Jun 15 10:42 NAMESPACE
drwxrwxr-x 2 edd staff 4096 Jun 15 10:42 R
/usr/local/lib/R/site-library/digest/help:
total 36
-rw-rw-r-- 1 edd staff 80 Jun 15 10:42 aliases.rds
-rw-rw-r-- 1 edd staff 32 Jun 15 10:42 AnIndex
-rw-rw-r-- 1 edd staff 17857 Jun 15 10:42 digest.rdb
-rw-rw-r-- 1 edd staff 193 Jun 15 10:42 digest.rdx
-rw-rw-r-- 1 edd staff 140 Jun 15 10:42 paths.rds
/usr/local/lib/R/site-library/digest/html:
total 8
-rw-rw-r-- 1 edd staff 1236 Jun 15 10:42 00Index.html
-rw-rw-r-- 1 edd staff 1179 Jun 15 10:42 R.css
/usr/local/lib/R/site-library/digest/libs:
total 120
-rwxrwxr-x 1 edd staff 118956 Jun 15 10:42 digest.so
/usr/local/lib/R/site-library/digest/Meta:
total 20
-rw-rw-r-- 1 edd staff 351 Jun 15 10:42 hsearch.rds
-rw-rw-r-- 1 edd staff 117 Jun 15 10:42 links.rds
-rw-rw-r-- 1 edd staff 224 Jun 15 10:42 nsInfo.rds
-rw-rw-r-- 1 edd staff 1271 Jun 15 10:42 package.rds
-rw-rw-r-- 1 edd staff 331 Jun 15 10:42 Rd.rds
/usr/local/lib/R/site-library/digest/R:
total 16
-rw-rw-r-- 1 edd staff 1056 Jun 15 10:42 digest
-rw-rw-r-- 1 edd staff 4168 Jun 15 10:42 digest.rdb
-rw-rw-r-- 1 edd staff 388 Jun 15 10:42 digest.rdx
R Under development (unstable) (2013-06-14 r62964) -- "Unsuffered Consequences"
Copyright (C) 2013 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.