[Rd] R-1.2.3: a small suggestion (PR#961)
Sun, 3 Jun 2001 19:16:43 +0200
>>>>> 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?
>> ...is not good enough. Emacs has added [the equivalent of]
>> 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)
>  "/usr/local/lib/R-1.3.0/library"
>  "/usr/local/lib/R-1.2.3/library"
>  "/usr/local/lib/R-1.2.2/library"
>  "/usr/local/lib/R-1.2.1/library"
>  "/usr/local/lib/R-1.2.0/library"
>  "/usr/local/lib/R-1.1.1/library"
>  "/usr/local/lib/R-1.1.0/library"
>  "/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)
> 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
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 ...
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: firstname.lastname@example.org