MacOS X: update.packages(type="mac.binary") fails (PR#7836)

Message 2 of today: it works now.

After re-installing R.app from the same R-2.1.0.dmg file, and
fixInNamespace'ing(*) install.packages(), I managed to update 23
outdated packages from CRAN binaries for MacOS X. What I did was to:

1. change call to .install.macbinaries() into call to install.binaries()
in install.packages(). install.binaries() is a function defined
utils/R/aqua/GUI.R.
2. I also had to remove argument 'dependencies' since that is not
defined in install.binaries() of utils/aqua.

It seems that install.binaries of utils/aqua is mentioned in several
places in R sources, but .install.macbinary() appears only in one place,
so changing install.packages() is less hassle than changing
utils/R/aqua/GUI.R and all other places (although this looks more
natural).

This still requires a fix in passing type in update.packages() that B.
Ripley already did for R 2.1.1, or setting
options(pkgType="mac.binary").

cheers, jari oksanen

(*) "Object-oriented programming is an exceptionally bad idea which
could only have originated in California." E. Dijkstra

On Tue, 2005-05-03 at 16:14 +0100, Prof Brian Ripley wrote:

Binary installs are AFAIK only supported in the GUI, where the default is
as documented.  So .install.macbinary() is not loaded except in the GUI.

The reason is that those binaries are tied to that particular build of R,
and will not work with a general build on MacOS X.

I would expect this to work from the command-line in the GUI console, and
had believed it had been tested there.


On Tue, 3 May 2005 jari.oksanen@oulu.fi wrote:

Full_Name: Jari Oksanen
Version: R 2.1.0
OS: MacOS 10.3.9
Submission from: (NULL) (130.231.102.145)


For various reasons (which need not be expanded here) I have tried to update my
long neglected R in MacOS X using handy command line tool update.packages()
using readily available binaries of contributed packages at CRAN. However, this
fails with message saying that packages xxxx_*_tar.gz is not found at the server
(HTTP error 404). Obviously, the package name is expanded wrongly as the binary
packages for MacOS X have type *.tgz. However, this seems not be the problem,
but there are two other problems:

1. update.packages does not transfer the value of 'type' to the next function
install.packages, but install.packages uses the value of getOption("pkgType")
which seems to be "source" in CRAN binary of MacOS X (contrary to documentation
at ?options).

2. If this is corrected, or first set options(pkgType="mac.binary"), the update
fails for missing function .install.macbinary().

The first problem is easy to correct:

--- update.packages.R   2005-05-03 17:13:36.000000000 +0300
+++ jarioksa.update.packages.R  2005-05-03 17:13:58.000000000 +0300
@@ -59,5 +59,5 @@
         install.packages(update[, "Package"], instlib, contriburl =
contriburl,
             method = method, available = available, destdir = destdir,
-            installWithVers = installWithVers, type)
+            installWithVers = installWithVers, type = type)
     }
 }


For the second, problem, I don't know what to do. grepping
R-patched_2005-05-03.tar.gz source found only one instance of
.install.macbinary(): the failed call in
R-patched/src/library/utils/R/packages2.R. I couldn't find the definition of the
function.

Do I really have to use GUI? Uh.

cheers, jari oksanen

This still requires a fix in passing type in update.packages() that B.
Ripley already did for R 2.1.1, or setting
options(pkgType="mac.binary").

This should not be required. What does .Platform say?

This should not be required. What does .Platform say?

str(.Platform)

R.version.string

On Wed, 2005-05-04 at 09:01 +0100, Prof Brian Ripley wrote:

This should not be required. What does .Platform say?

I couldn't let it be:

str(.Platform)

List of 6
$ OS.type   : chr "unix"
$ file.sep  : chr "/"
$ dynlib.ext: chr ".so"
$ GUI       : chr "AQUA"
$ endian    : chr "big"
$ pkgType   : chr "source"

R.version.string

[1] "R version 2.1.0, 2005-04-18"

(After removing R.app and R.framework, re-installing from R-2.1.0.dmg,
logging out and in -- the last step helped.)

As this is "CRAN Mac OS X build" this seems to be in conflict with
documentation of 'options' "pkgType".

PS.

download.packages("AMORE", type="source", destdir="/tmp")

works in MacOS X (or this one I have here) with any 'type'.

cheers, jari oksanen
-- 
Jari Oksanen -- Dept Biology, Univ Oulu, 90014 Oulu, Finland
Ph. +358 8 5531526, cell +358 40 5136529, fax +358 8 5531061
email jari.oksanen@oulu.fi, homepage http://cc.oulu.fi/~jarioksa/