[R-sig-Debian] Problem updating packages in 2.15.1 on Ubuntu 12.04
Paul Johnson
pauljohn32 at gmail.com
Thu Aug 2 19:39:39 CEST 2012
Greetings
On Thu, Aug 2, 2012 at 4:55 AM, Chris Evans <chrishold at psyctc.org> wrote:
> Paul Johnson sent the following at 01/08/12 16:01:
>
>> On Wed, Aug 1, 2012 at 1:02 AM, Chris Evans <chrishold at psyctc.org>
>> wrote:
>>>
>>> The specific message is: "Warning: package 'spatial' in library
>>> '/usr/lib/R/library' will not be updated"
>>>
>>> and the number of libraries about which that's the complaint is now
>>> increasingly almost daily so clearly something is wrong.
>>>
>> Yes, the something wrong is the system administrator :)
>
>
> Sweet of you to confirm what I myself said ("Clearly I don't understand
>
> something and am doing something wrong. Please can someone enlighten
> me?") However, I am only as good as the information I can find and I
> honestly don't think that's very clear but let's move on from that bit
> of who's the wrong one.
>
People often say I'm sweet :)
>
>> Please remember that you have a choice of installing R packages from
>> the R repositories using install.packages (or update.packages). That
>> downloads source code, compiles and installs. Generally, on Debian,
>> it will install to /usr/local/lib/R/site-library. But you may also
>> install them as Debian packages that have been built on somebody
>> else's system and wrapped up for your usage. Those generally install
>> into /usr/lib/R/site-library.
>
>
> Are these mutually exclusive ways of doing things? If so, I think we
> should have a much clearer statement to that effect somewhere. If not,
> and I had assumed they were not, it would be useful to be told why the
> two different library locations are used and how R handles things when
> it may find copies of the same library in different library locations.
>
This is a decision made by the R packager of your Linux distribution,
not by the R team. This pattern you are looking at is unique to
Debian, although I noticed what Dirk was doing on Debian and thought
it was really good, and I explained it to the RedHat packager, and
they are doing something similar now.
It is a convenient policy, to use /usr/lib/R/library for the packages
distributed with R,
/usr/lib/R/site-library for the packages built as Debian packages, and then
encourage users who install their own to use /usr/loca/lib/R/site-library or
~/R.
I don't use Debian packages very often because I, like you, want to
compile my own.
In order to diagnose your trouble, please lets concentrate on one
problem at a time. Do what I do now. Open a terminal. You run
$ sudo R
and then inside R, run this
> install.packages("spatial", dep=T, repos="http://rweb.quant.ku.edu/cran")
I put my repos there because I'm reasonably sure it does not suck. I
can't speak
to other servers.
I us install.packages because it gives us a clear avenue to track
what's going on.
On my Debian system, here's what I see when I do that
> install.packages("spatial", dep=T, repos="http://rweb.quant.ku.edu/cran")
Installing package(s) into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)
trying URL 'http://rweb.quant.ku.edu/cran/src/contrib/spatial_7.3-4.tar.gz'
Content type 'application/x-gzip' length 44360 bytes (43 Kb)
opened URL
==================================================
downloaded 43 Kb
* installing *source* package ‘spatial’ ...
** package ‘spatial’ successfully unpacked and MD5 sums checked
** libs
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -fpic -O3 -pipe
-g -c init.c -o init.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -fpic -O3 -pipe
-g -c krc.c -o krc.o
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -fpic -O3 -pipe
-g -c pps.c -o pps.o
gcc -std=gnu99 -shared -o spatial.so init.o krc.o pps.o -L/usr/lib64/R/lib -lR
installing to /usr/local/lib/R/site-library/spatial/libs
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (spatial)
The downloaded source packages are in
‘/tmp/RtmptdCZdg/downloaded_packages’
#############################################
That gives me 2 copies of spatial, one installed from the Debian
package r-cran-spatial, and the one I just compiled.
We need to see the entire output you get when you run the same.
Note that it put the package into /usr/local/lib/R/site-library
because I'm building this by hand.
How did it know to do that? Check the file:
/etc/R/Renviron
and look for:
R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
When you run the command, please include everything in the output, even
he parts you think might not be relevant.
I'm cutting all the rest of your stuff below because we need to get to
the bottom
of the one problem first, and the best way to do that is what I say
above. I can say for sure your compile of RGtk2 fails because you
don't have the development packages installed. That's what it means
when it says:
checking for GTK... no
Also, the other errors you see are related to user privileges. If you
forget to "sudo" before R, you are running as a non-root user. Look
what I get when I do that:
> update.packages()
--- Please select a CRAN mirror for use in this session ---
Loading Tcl/Tk interface ... done
Warning: package 'rgl' in library '/usr/lib/R/site-library' will not be updated
Warning: package 'MASS' in library '/usr/lib/R/library' will not be updated
Warning: package 'mgcv' in library '/usr/lib/R/library' will not be updated
Looks just like your errors, doesn't it??
I'm not an unkind person, I'm not trying to insult you by ignoring the
rest of your message. Lets fix one thing at a time.
As for your complaint that nobody has written out all the details of
why things work this way in Debian, well, I suppose you could be the
one to write it all out :). If you get a handle on how this works,
you could post a blog explanation and we'd all benefit by being able
to refer users to it. That's how stuff gets done.
How did I learn about this packaging policy? I'm pretty sure I asked
in this list, and was told the information is in the file that is
distributed with the Debian package r-base-core,
/usr/share/doc/r-base-core/changelog.Debian.gz,
* debian/rules: Add R_LIBS setting to /etc/R/Renviron such that
user-installed packages will be in /usr/local/lib/R/site-library,
Debian packages will install into /usr/lib/R/site-library and
the r-base-core and r-recommended packages will use the standard
/usr/lib/R/library directory
I know for sure from previous debates here that the Debian packagers
expect you to use the packages they provide, and they don't think
"ordinary" users should bother trying to compile packages. That does
not speak to the fact that you may not have access to an up-to-date
repository for packages for your particular system. John Nash pointed
you at one that will work for you.
pj
--
Paul E. Johnson
Professor, Political Science Assoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org http://quant.ku.edu
More information about the R-SIG-Debian
mailing list