[BioC] Library installation: odd error

[Michael Bauer]

On 7/12/2011 9:05 PM, Steve Lianoglou wrote:
> 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>
>>>   wrote:
>>>> I am a system administrator at a site with several R users.  In response
>>>> to
>>>> a previous set of questions, we were encouraged to have individual users
>>>> set
>>>> up R library directories in their home directories and use the R
>>>> environment
>>>> variables to direct R to put auto-installed libraries there.
>>>>
>>>> However, we've run across one consistent problem: the library that
>>>> prompted
>>>> this whole string will not install on Linux.  (It installs just fine in R
>>>> on
>>>> Windows.)  When presented with a writable library directory to install
>>>> into,
>>>> 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:
>>> http://thread.gmane.org/gmane.comp.ai.machine-learning.shogun/2020
>>>
>>> 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.
>>>
>>> HTH,
>>>
>>> -steve
>>>
>>> [*] 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
>> installs.
> 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:
>
> R>  install.packages('glmnet')
>
> It actually requires a FORTRAN compiler, so if that gives you
> problems, maybe you can try plyr
>
> R>  install.packages('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
> option:
>
> R>  source("http://bioconductor.org/biocLite.R")
> R>  pkgs<- rownames(installed.packages())
> R>  biocLite(pkgs)
>
> Although I'm pretty sure the option listed before that on that install
> page would work all the same ...
>
> -steve
>

As it turns out, yes, the old libraries were the obstruction.  The new R 
I built worked fine until I added either one of the old library 
directories to R_LIBS.  So now I have the joy of ripping out all the 
existing R libraries and replacing them with ones that people still want 
system-wide -- fortunately a far smaller set.

Thanks for the help!

MJB