[R] how to get old packages to work on R 2.12.1

Joshua Wiley jwiley.psych at gmail.com
Wed Jan 19 18:43:49 CET 2011

Dear Joe,

On Wed, Jan 19, 2011 at 7:49 AM, Joseph Boyer <joseph.g.boyer at gsk.com> wrote:
> I just installed R 2.12.1, and when I went to run a few old programs with it, nothing worked.
> I got a ton of error messages saying such and such package was built before R 2.10.0 and needed to be reinstalled.
> These were not just warning messages, but error messages that prevent the programs from running when
> they were running just fine with R 2.10.1
> For some of those packages, such as deSolve, I can't find any recent versions to download to correct the problem.
> So my first question is, is there a way around this error that doesn't require actually installing recent versions of all those old packages?
> I suppose I could just use R 2.10.1, but suppose at some point I want to use both an old package and a new package that was built
> under R 2.12.1 in the same program? That has happened by the way. I wanted to use deSolve and yags. Since I don't have an old version of yags,
> I had to install the current version on CRAN, and it won't work under 2.10.1.

This is not an option for your current problem, but if backwards
compatibility is important, keep backups.  I borrowed this idea from
Debian which has stable and unstable versions.  The stable ones are
"frozen"---no more updates are done (not 100% true, but that is the
gist).  R is very well behaved about having multiple installs, so I
typically install new versions in a new directory and then install all
my packages again (I keep an R script for this).  Once I am satisfied
that everything I want to do works in the latest and greatest version
of R + updated packages, I can delete the old versions, otherwise, I
just keep both.  Storage is available cheaply (< .05 USD per
gigabyte), so unless you're installing all of CRAN, it should not cost
much to keep duplicates.

> My second question is, if not, should the R developers reconsider their strategic decision to invalidate packages just because they were built
> under early versions of R?

I do not believe that packages are invalidated because of their
version.  There are instances where old code no longer works, and some
newer packages may also require more modern versions of packages
because either the package maintainers know the older package versions
do not work as they want, or they are unsure and unwilling to deal
with the hassle.  In any case, everything I have seen suggests that
the R core team is very aware of compatibility issues and does as much
as possible to keep R core stable and compatible.  There have been
quite a few discussions on the R-devel list about new features etc.
that invariably include a discussion of what the ramifications of
change would be and whether or not it is justified.

> I would be willing to bet that for many users, the improvements from R 2.10.1 to R 2.12.1 are minor compared with the hassle caused by the fact
> that their old programs will no longer work.
> This especially complicates application development, where the R programmer is not the end user.
> What developer is going to use R for his applications if he can't even be sure they will work under future versions?

I think many would, do, and will.  Improvement and progress
necessitate change (I suspect most developers are thrilled not to be
stuck using paper tape in batch mode [and my sincerest condolences to
those who still fondly remember and lament the loss]).  The R core
team is very good about giving advance warning and providing R-devel
before it is officially released which allows software developers to
start working with the new code and updating their programs if
necessary before the latest version of R is rolled out to general

I know it is frustrating and a hassle when something that used to work
stops (I currently work with Windows 7 x64, Windows XP x32, and Debian
unstable---trying to keep all three up-to-date and working similarly
keeps me on my toes and if half the things I've muttered under my
breath about computers at 2am actually came to pass.....), but also
consider that the R core team already freely volunteer their time and
(vast) skill to provide us this wonderful software.  I do not think it
is too much to ask that software developers and users be willing to
put in some of their own time to update when there are changes and
improvements to R that are, ultimately, benefiting us anyways.  If it
is truly too much bother and hassle for minor improvements, it may be
better to only upgrade R versions at major releases (1, 2, 3, etc.).
My school seems to have taken this approach and still has 1.8.1, I
think, loaded on their lab computers.

My $.02 (or$.05)



> Joe Boyer
> Principal Statistician
> GSK Department of Statistical Sciences
> 8-275-3661
> external: 610-787-3661
>        [[alternative HTML version deleted]]
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

Joshua Wiley
Ph.D. Student, Health Psychology
University of California, Los Angeles

More information about the R-help mailing list