[BioC] Library installation: odd error
mailinglist.honeypot at gmail.com
Wed Jul 13 03:05:06 CEST 2011
On Tue, Jul 12, 2011 at 6:21 PM, Michael Bauer <mjbauer at eecs.tufts.edu> wrote:
> On 7/12/2011 4:06 PM, Steve Lianoglou wrote:
>> Hi Michael,
>> On Tue, Jul 12, 2011 at 3:47 PM, Michael Bauer<mjbauer at eecs.tufts.edu>
>>> I am a system administrator at a site with several R users. In response
>>> a previous set of questions, we were encouraged to have individual users
>>> up R library directories in their home directories and use the R
>>> variables to direct R to put auto-installed libraries there.
>>> However, we've run across one consistent problem: the library that
>>> this whole string will not install on Linux. (It installs just fine in R
>>> Windows.) When presented with a writable library directory to install
>>> it the installation invariably fails with the error:
>>> Error in ret[i, ]<- c(pkgs[i], lib, desc) :
>>> number of items to replace is not a multiple of replacement length
>> I'll cut here.
>> This has happened to me recently. Any time I tried to install
>> *anything* I would get this error.
>> So, first question: is it only when you try to install a particular
>> package that this happens, or are all package-installs now hosed?
>> I'm going to assume that all package installs are not working.
>> This error was happening to me because there is a package that is
>> *already* installed in the system which is "corrupt". I had installed
>> a library that "hand crafted" its own installation, and I guess the
>> meta-data that R requires a package to have has changed over time
>> causing this custom-installed-package to trip things up.
>> The details of my situation and how I fixed it are here:
>> The details of your problem are likely different -- but maybe this
>> will help you find the offending package (if one exists)?
>> Is there some package that was installed in a non-traditional manner?
>> If you compare the output of `installed.packages()`[*] between your
>> linux and windows install, you can find which packages are installed
>> on the linux machine and not the windows machine that might be causing
>> these problems.
>> [*] you probably want to use `installed.packages()[,1]` since the
>> object returned from the function call is a matrix.
> So far as I know, I'm the only one who would have altered our system-wide
> installation of R, and I've followed installation instructions on each
> occasion. I'll check out the one that caused you havoc (sg) as we also have
> that one installed, but the datestamp on it is from 2009, and we've
> successfully installed quite a bit since then.
Heh .. that's pretty funny. I wonder if it's too late for me to go out
and buy a lotto ticket tonight ...
> That datestamp, on the other hand, makes me suspect that several of our R
> libraries are significantly out of date. As a simple check, I'm building R
> from scratch in an alternate directory and will see if it can handle
Dollars to donuts it will.
> One question: is there any R configuration directory that I should be
> looking in for environment changes, or is everything handled through
> environment variables in the appropriate shell configuration?
The R shell script should handle most of that, so I guess you can peak
through that to see what it's doing.
Also, each user can have an .Rprofile file in their home directory
(~/.Rprofile) that R will normally load so that the user can tweak
his/her R environment as they please.
Something else regarding what you mentioned about old timestamps on
many of your libraries: that seems like a bad thing in general,
especially since (if I remember correctly) you said you're running the
latest version of R (2.13.x).
R libraries that were build for one version of R shouldn't be copied
over and used in new R versions.
If I were you, and was looking for a quick fix, I'd:
(1) move that sg package out of the way for now, ie. move the `sg`
directory outside of your R's library directory (you can fix it later
using the info from that posting to that shogun list I sent
previously, once everything is back to normal).
(2) Try to install a random package to make sure that the `sg` package
was the one causing the problem. glmnet is always handy to have:
It actually requires a FORTRAN compiler, so if that gives you
problems, maybe you can try plyr
(3) Assuming (2) worked, now update your installed packages from
within R as described on the bioconductor install page
(http://www.bioconductor.org/install/) -- perhaps using the nuclear
R> pkgs <- rownames(installed.packages())
Although I'm pretty sure the option listed before that on that install
page would work all the same ...
Graduate Student: Computational Systems Biology
| Memorial Sloan-Kettering Cancer Center
| Weill Medical College of Cornell University
Contact Info: http://cbio.mskcc.org/~lianos/contact
More information about the Bioconductor