[R-sig-Debian] update.packages() as ordinary user, /usr/lib/R/site-library is not writable

[Johannes Ranke]

Dear Chris,

I am just keeping some parts of the thread below that I have not answered yet:

> All that begs the question how I got myself here.  

I think it was really a bug in the README on CRAN. I wrote that you can run a 
regular update of R packages using update.packages() which is not generally 
the case. I have updated the respective sections in the README (will hit CRAN 
within the next day) and would be glad about feedback.

> I think the learning
> point is that there may be a way to make the instructions in the deb
> packages in stable (well, in the next stable I guess) spell out the
> relationship between the deb repository in stable, the deb repository in
> CRAN (with a link to the page in CRAN about the debs there) and the
> non-deb libraries in CRAN.  You might spell out options which I have as:
> 1) you can stay with the debs in stable, and update within R as an
> ordinary user, you won't get automatic R updates but you should get the
> package updates that are possible for that version of R
> 2) you can go with the debs in CRAN which will usually give you the
> latest version of R shortly after it is released.  In that  case [just
> my take and I can see that I could be quite wrong] you are best off
> doing  a complete remove of the version of R you installed from your
> Debian stable mirror using synaptic (or your own preferred package
> handler), _before_ adding the necessary line in /etc/apt/sources.list to
> get your local CRAN deb repository, after which you can do a clean
> install of R
> 3) you are probably wise to do adduser yourself staff to get write
> access to /usr/local/lib/R/site-library/
> 4) you should then find that things update fine through R and
> update.packages() running R as an ordinary user and you will be getting
> the latest R very soon after each upgrade and the latest upgrades of the
> packages you have installed.
> 
> It sounds to me as if there's another option which is use the debian
> backports deb repository/mirror but I'm not sure I understand the
> relationship between that option and the option of going to the CRAN debs.

We have discussed this option on this list before. If there would be a 
volunteer Debian developer that would like to step up and take on the job of 
uploading backported packages to lenny-backports and squeeze-backports, we 
would really not need the repository on CRAN. The job would not be very 
difficult I think. At the moment Dirks packages from unstable compile without 
modifications on squeeze and only a couple of minor dependency issues have to 
be taken care of for lenny, at least as far as the set of packages is 
concerned that are currently on CRAN. It's just that I am afraid of taking on 
the challenge to become a Debian developer.

Regards to all,

Johannes

> 
> Very best all & thanks again to you both Dirk & Johannes,
> 
> Chris
> 
> 
> ... rest of Johannes's reply and the thread follows for the record ...
> 
> > The other packages should (please correct me if I am wrong Dirk)
> > remain under control of the Debian package management.
> > 
> > If you want to update such packages as well, you need to bug me or
> > help me in creating those backports (or use apt pinning e.g. to
> > testing, but I think this would make things too complicated). For
> > example, I only update R base packages on CRAN/Debian (like
> > r-cran-foreign, r-cran-nlme etc.) when a new R version is released.
> > And there are a lot of packages that Dirk meticulously updates in
> > Debian unstable that I have never backported for Debian stable, like
> > r-cran-xml and r-cran-rgl.
> > 
> > Regards,
> > 
> > Johannes
> > 
> > P.S.: I also mainly use my own R distribution for Debian stable on
> > servers, just recently started to use it on my laptop (going back from
> > Ubuntu).
> > 
> >> So now I'm baffled as to how to be friendly with R and linux/Debian
> >> on this machine!
> >> 
> >> Perhaps I should say that I would like to work by:
> >> 1) having the cran deb line in /etc/apt/sources.list and doing basic
> >> installation of R from there as my understanding is that that will
> >> get me the latest R for Debian when you (plural) have rolled it and
> >> put it on CRAN getting me round the downloading and replacing I used
> >> to do on windoze and also making it pretty likely that you'll have
> >> sorted out dependency problems etc.
> >> 2) would like then to rely on update.packages() from within R
> >> 3) but running as local user as I can see the logic of that
> >> 
> >> #1 and #2 are what I've always done on my Debian web server (where I
> >> was running some cgi-bin scripts invoking R) but I always did the
> >> update.packages() as root.  I've now moved that server to a shell
> >> account at mythic-beasts (great guys) so I'll have to do #3 for that
> >> too in future and though I could update as root on this laptop I do
> >> see the logic of not doing that and clearly you both and presumably
> >> many others on this list do #1, #2 and #3 so why is it not working
> >> for me?!
> >> 
> >> Suggestions gratefully received!
> >> 
> >> Very best & karma to all,
> >> 
> >> Chris
> >> 
> >> Dirk Eddelbuettel sent the following  at 21/09/11 13:49:
> >>> Hi Chris,
> >>> 
> >>> Thanks for patient follow-up even after I (as Johannes noted) evidently
> >>> overlooked key parts of your first email.
> >>> 
> >>> On 21 September 2011 at 07:49, Chris Evans wrote:
> >>> | I ran synaptic from the Debian application menu which defaults to
> >>> 
> >>> root
> >>> 
> >>> | after askling for the root password the first time I invoke it
> >>> 
> >>> after a
> >>> 
> >>> | reboot. (I probably should have said that I've been using Debian
> >>> 
> >>> for my
> >>> 
> >>> | internet server work for about 15 years: I'm not a Debian/linux
> >>> 
> >>> newbie,
> >>> 
> >>> | just someone finally throwing away the reins from M$ to have a laptop
> >>> | running Debian as well!)
> >>> 
> >>> Perfect.
> >>> 
> >>> | I get that from invoking update.packages() in an R session
> >>> 
> >>> launched from
> >>> 
> >>> | a user (chris) terminal session. Before that I had done an install of
> >>> 
> >>> I do that too, as well as calling the 'install.r' helper script from
> >>> littler
> >>> (in its examples/ diretory, if interested).
> >>> 
> >>> This requires that you make /usr/local/lib/R/site-library/ writable
> >>> for _you_
> >>> as user chris, else you cannot.
> >>> 
> >>> [ It also assumes that the Renviron setting mentioned last time is
> >>> still
> >>> valid, do this:
> >>> 
> >>> edd at max:~$ R -q -e 'print(.libPaths())'
> >>> R>  print(.libPaths())
> >>> [1] "/usr/local/lib/R/site-library" "/usr/lib/R/site-library"
> >>> "/usr/lib/R/library"
> >>> R>
> >>> R>
> >>> 
> >>> It _must_ be first as here.  ]
> >>> 
> >>> Now, /usr/local/lib/R/site-library/ comes shipped from the r-base-core
> >>> package as owned by group 'staff' so one solution is to add yourself
> >>> to group
> >>> staff:
> >>> 
> >>> edd at max:~$ ls -ld /usr/local/lib/R/site-library/
> >>> drwxrwsr-x 136 root staff 4096 2011-09-20 07:44
> >>> /usr/local/lib/R/site-library/
> >>> edd at max:~$ id
> >>> uid=1000(edd) gid=1000(edd)
> >>> groups=1000(edd),4(adm),20(dialout),24(cdrom),27(sudo),44(video),46(plu
> >>> gdev),50(staff),[.....]
> >>> 
> >>> edd at max:~$
> >>> 
> >>> If those two conditions are met, you should be able to run
> >>> install.packages()
> >>> as you.  I still prefer it from the shell as I sometimes need
> >>> another apt-get
> >>> call for a missing library etc.
> >>> 
> >>> | I wouldn't dream of compiling locally anything I can get from a
> >>> 
> >>> deb you
> >>> 
> >>> | rolled!!
> >>> :
> >>> :-)
> >>> :
> >>> | However, I come back to feeling that there must be three separate
> >>> | problems here that come from within the packages I added after the
> >>> | initial r-cran-base install. My hunch is that there are things
> >>> 
> >>> with XML
> >>> 
> >>> | and rgl that I will be able to track down when restrict to just
> >>> 
> >>> updating
> >>> 
> >>> "I would not dream of compiling locally" either.  You could start by
> >>> locally
> >>> re-building the packages.  Which requires the build depends.
> >>> 
> >>> | them but that at the moment there is a more global problem which I'm
> >>> | guessing is caused by one package overriding the order of library
> >>> 
> >>> path
> >>> 
> >>> | options seen in .libPaths() which starts with a perfectly writable
> >>> 
> >>> local
> >>> 
> >>> | user directory and I am guessing there is some way that package has
> >>> | insisted that the install tries /usr/lib/R/library.
> >>> 
> >>> Agreed on the first bit.  I think /usr/lib/R/library -- where we as
> >>> users
> >>> should never tread as it is /usr which belongs to apt/dpkg -- is
> >>> just the
> >>> fallback.  Somehow the value got nuked.
> >>> 
> >>> | I don't know enough about the way that R and linux work agree the
> >>> 
> >>> use of
> >>> 
> >>> | those library location options. From ?.libPaths and a bit more
> >>> 
> >>> hunting
> >>> 
> >>> | around the R help I had the impression that the .libPath options
> >>> 
> >>> would
> >>> 
> >>> | be used in order. I think I can remove the /usr ones by hacking in
> >>> 
> >>> Correct.
> >>> 
> >>> | /etc/R but that presumably risks losing access to the main libraries
> >>> | that will have been installed there so that doesn't look a good step
> >>> | forward except perhaps to debug things.
> >>> 
> >>> An easier option ... is to _explicitly add_ the
> >>> /usr/local/lib/R/site-library/ destination as an argument to
> >>> install.packages!
> >>> 
> >>> | I suspect that I could do a complete remove of all of R, start again
> >>> | installing r-cran-base, check that R installed by that updates
> >>> 
> >>> fine run
> >>> 
> >>> | by a user and then I could use synaptic to add the additional deb
> >>> | packages you provide but doing that one by one and running R and
> >>> | update.packages() after each one to see if I don't hit this until
> >>> 
> >>> afetr
> >>> 
> >>> | a particular deb but that's going to take quite a long time so I
> >>> | wondered if you or the list had quicker suggestions to debug this.
> >>> 
> >>> That sounds too involved.
> >>> 
> >>> | Sorry for length but hope that's clearer (got to try to be an
> >>> 
> >>> acceptable
> >>> 
> >>> | friend on R lists as well as with linux and I really, really do
> >>> | appreciate the generosity of this list).
> >>> 
> >>> No sweat. We're all just building karma :)
> >>> 
> >>> Dirk
> >> 
> >> _______________________________________________
> >> R-SIG-Debian mailing list
> >> R-SIG-Debian at r-project.org
> >> https://stat.ethz.ch/mailman/listinfo/r-sig-debian