On 09-Apr-05 Prof Brian Ripley wrote:
> The known problems are in the file
>
> http://www.r-project.org/nocvs/R.check/r-devel/norm-00check.txt
>
> No showstoppers, so given the saga of Ted's connectivity, I would
> suggest waiting for the release on April 18.
>
> There are no declared dependencies, nor did I find any searching the
> code.
Thanks for the pointer. Yes, they look innocuous enough.
On the precautionary principle, however, it would be worth
dealing with the ".Fortran" warnings, since this would
safeguard against the possibility of name clash if some
other package used the same names.
Question 1:
I take it that all that's needed here is to search for
all such calls, e.g.
.Fortran("tobsn", ...)
and make sure that it one becomes
.Fortran("tobsn", ... ,PACKAGE=norm)
and so on?
This could be done without installing any new R (though
being able to check against the latest would be added
assurance), as also could be possible amendements related
to the "Rd" warnings (which, however, only affect "help"
and other documentation issues).
None the less,
Question 2.
It would still be interesting to test out the compilability
of the latest R on the machine I would be installing the
new one on anyway (SuSE Linux 7.2 from 2001), since this
would have oldish math libs ...
I think I have sussed out how to keep different versions
of R on the same machine, namely:
a) Edit /usr/bin/R and change
R_HOME_DIR=/usr/lib/R
to
R_HOME_DIR=/usr/lib/R-x.y.z
as appropriate.
b) Rename the directory /usr/lib/R to /usr/lib/R-x.y.z
c) Rename /usr/bin/R to /usr/bin/R-x.y.z
d) (pro tem) Make a symbolic link
ln -s /usr/bin/R-x.y.z /usr/bin/R
Then one can install a new R without thinking about it,
provided one remembers to delete the symbolic link before
starting (or will the new installation do this all by
itself?).
Have I missed anything?
Thanks, and best wishes,
Ted.
______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
