[Rd] R-1.2.3: a small suggestion (PR#961)

[Kurt Hornik]

>>>>> Peter Dalgaard BSA writes:

> Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:
>> With me quickly getting there this morning ...
>> 
>> 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?

> Well... 

>> ...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.

> Instinctively, I don't think we want to go there... Wouldn't one end
> up with (the equivalent of)

>> .lib.loc
> [1] "/usr/local/lib/R-1.3.0/library"
> [2] "/usr/local/lib/R-1.2.3/library"
> [3] "/usr/local/lib/R-1.2.2/library"
> [4] "/usr/local/lib/R-1.2.1/library"
> [5] "/usr/local/lib/R-1.2.0/library"
> [6] "/usr/local/lib/R-1.1.1/library"
> [7] "/usr/local/lib/R-1.1.0/library"
> [8] "/usr/local/lib/R-1.0.1/library"

> ??

Yes.  What a nightmare.

[We potentially have control over this, though, through the Depends info
in the package DESCRIPTION dbs.  E.g., update.packages() could try to
organize packages with R version dependencies into version-dependent
subdirs.  But again: suppose pkg A depends on R version B and package B
which may be available but need another version of R.  So we may need
the version of package B for the same version of R etc etc ...]

I think we are much better off with the current `always take the most
current one' approach.

>> But the effort is really only worth it when one is interested in having
>> different versions installed at the same time.  Otherwise, you can
>> always do
>> 
>> make install
>> (cd PREFIX/lib; mv R R-VERSION)
>> 
>> yourself.

> Um, I did that once and the walls came tumblin' down... (Or rather, I
> tried to move the existing install out of the way before installing a
> new one.) You also need to fixup the R_HOME_DIR variable in the R
> script as Beebe mentioned.

Of course.  But then how do you invoke R?  You either follow Emacs and
have

	R-1.2.3
	R-1.3.0

in your PATH somewhere, or you have a command line option for setting
the version.  And then we're back to the above, worrying about (mostly
binary but not necessarily so; what if there is a change in the
documentation system?) version dependencies in your site tree.

>> Developers, as PD says, typically rely on running their development
>> version from BUILDDIR.  Otoh, this is wrong because they could end up
>> with an incompatible add-on package in the site tree.  

> Er, how? 

>> And we are back
>> to the long-made decision that God did not want us to run multiple R
>> versions at the same time.

> IF we drop the "easy package migration" aspect and just let people do
> separate installs with separate generation of site libraries, would we
> not be in the clear? There's also an issue with private libraries of
> course. Versioning those would put some administrative burden on the
> end user, but could we not adapt an "if it breaks, you get to keep
> both pieces" policy?

See above.  You're saying `tell everyone that they can do FOO to get
multiple version trees but then they're on their own'.  And then we get
all kinds of bug reports ...

-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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._