[This is not a bug report, just a suggestion.]
With complex packages, it is often useful to maintain multiple
versions installed, for bug checking, and performance comparisons, and
for developers, for a development history (e.g., I have about 30
versions of ghostscript, whose development I contribute to, and I have
on several occasions run tests files on with each them to find out
when a change in behavior was introduced).
The common way to do this is to suffix a version number to the
executable and any file tree(s) that it requires.
The R-1.2.3 release does not currently do this, but it looks like only
a couple of lines of changes are needed to accomplish the job, and
I've done so locally manually.
(1) In the R script, change
R_HOME_DIR=/usr/local/lib/R
to
R_HOME_DIR=/usr/local/lib/R-1.2.3
and name the tree that way during installation.
(2) At installation time, first install the executable as
/usr/local/bin/R-1.2.3, then remove /usr/local/bin/R,
then do "ln -s R-1.2.3 /usr/local/bin/R" or
"ln R-1.2.3 /usr/local/bin/R", in that order. This
ensures that any existing version of R remains on the system,
accessible as R-x.y.z.
[Obviously, in the above, "/usr/local" is really
"$(prefix)".]
I suggest that the next round of R distribution consider incorporating
this change.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 -
- University of Utah Internet e-mail: beebe@math.utah.edu -
- Department of Mathematics, 322 INSCC beebe@acm.org beebe@computer.org -
- 155 S 1400 E RM 233 beebe@ieee.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Thu, 31 May 2001 beebe@math.utah.edu wrote:> [This is not a bug report, just a suggestion.] > > With complex packages, it is often useful to maintain multiple > versions installed, for bug checking, and performance comparisons, and > for developers, for a development history (e.g., I have about 30 > versions of ghostscript, whose development I contribute to, and I have > on several occasions run tests files on with each them to find out > when a change in behavior was introduced). > > The common way to do this is to suffix a version number to the > executable and any file tree(s) that it requires. > > The R-1.2.3 release does not currently do this, but it looks like only > a couple of lines of changes are needed to accomplish the job, and > I've done so locally manually. > > (1) In the R script, change > > R_HOME_DIR=/usr/local/lib/R > > to > > R_HOME_DIR=/usr/local/lib/R-1.2.3 > > and name the tree that way during installation. > > (2) At installation time, first install the executable as > /usr/local/bin/R-1.2.3, then remove /usr/local/bin/R, > then do "ln -s R-1.2.3 /usr/local/bin/R" or > "ln R-1.2.3 /usr/local/bin/R", in that order. This > ensures that any existing version of R remains on the system, > accessible as R-x.y.z. > > [Obviously, in the above, "/usr/local" is really "$(prefix)".] > > I suggest that the next round of R distribution consider incorporating > this change.There is a serious problem with that. All the user-installed packages in /usr/local/lib/R-1.2.3/library disappear from view on upgrade. They would need to be migrated. -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On 1 Jun 2001, Peter Dalgaard BSA wrote:> rossini@blindglobe.net (A.J. Rossini) writes: > > > >>>>> "r" == ripley <ripley@stats.ox.ac.uk> writes: > > > > r> There is a serious problem with that. All the user-installed > > r> packages in /usr/local/lib/R-1.2.3/library disappear from view > > r> on upgrade. They would need to be migrated. > > > > One thought would be to emulate XEmacs in this regard -- lisp packages > > are in equivalent of /usr/local/lib/R, while version-specific code is > > in the equivalent of /usr/local/lib/R-version. > > But R packages are not always binary compatible between releases. You > can't win. I think most of the development team just use the "run from > builddir" option.I do manually version-install almost as suggested for the dept copy (I would use /usr/local/lib/R/1.2.3 in the way that ghostscript does), which is why I know I need to manually migrate the packages. One can of course install packages in a private library. For my own installations I do, but it is not seamless, not least from the version-incompatibility of installed packages (and also that --vanilla stops the private library spec being picked up from .Renviron).> > Could we perhaps add a configure switch to install in R-$VERSION ? > > --versioned-install or something like that. Kurt? > > -- > O__ ---- Peter Dalgaard Blegdamsvej 3 > c/ /'_ --- Dept. of Biostatistics 2200 Cph. N > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 >-- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>>>>> Thomas Lumley writes:> On Fri, 1 Jun 2001, Kurt Hornik wrote: >> >> I had asked about multiple version (and also platform) support several >> times during the past few years, and had always been told that this was >> not necessary. So why does this keep coming up? >> >> One can add a version layer, but one has to do this right. Patterning >> after the Emacs model is wrong. Binary incompatabilities were pointed >> out, so >> >> PREFIX/lib/R/VERSION >> PREFIX/lib/R/site >> >> is not good enough. Emacs has added [the equivalent of] >> >> PREFIX/lib/R/site/VERSION >> >> but that requires external control of version dependency at install >> time. We actually have the required info through the DESCRIPTION db, >> hence could take care of this. >>> Are you sure we have the right info? We know if a package is > source-incompatible with old versions of R but we may not know if it > is binary-incompatible with new versions. I was surprised to find > that survival seems to be binary-incompatible between 1.2.3 and 1.3.0 > -- at least, several bugs went away when I recompiled with pre1.3.0Interesting. I thought this would not be the case. What you say is that a package may claim it only needs R 1.2.2 but this might not run under R 1.3.0 if compiled under R 1.2.2? But version incompatibilities go beyond binary incompatibilties. So even if we have the info I am not sure what to do. -k -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._