[Rd] robustness of install.packages/update.packages (was Re: bug in L-BFGS-B? (PR#8099))

[Prof Brian Ripley]

We've never encountered this lying mirror problem.  Perhaps you (or 
another user of the unreliable mirror) could contribute suitable fixes.

On Sun, 28 Aug 2005, Berwin A Turlach wrote:

> G'day Brian,
>
> I am splitting my reply to your e-mail into two since there are two
> separate spinoffs.
>
>>>>>> "BDR" == Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
>
>    BDR> Check your versions of MASS.  The Windows one appears to be
>    BDR> an outdated version, and does different things.
> Thanks, yes, this is the problem.  On my linux box, I compile things
> from source and had the latest version of MASS (7.2-19) installed
> under R 2.1.1 and R 2.2.0.
>
> Since I hardly ever work under Windows, I rely for my Windows box on
> the precompiled versions provided from CRAN and do not compile R or
> packages from source.  (Though I have it set up so that I can compile
> my own packages.)  Actually, I only installed R 2.1.1 on that machine
> (which has an AMD processor) yesterday and it was using MASS version
> 7.2-16.  Running `update.packages' today, updated MASS to version
> 7.2-18.  And, lo and behold, there are no more warning messages, even
> more, running the example in `fitdistr' now returns:
>
>> set.seed(123)
>> x <- rgamma(100, shape = 5, rate = 0.1)
>> fitdistr(x, "gamma")
>     shape         rate
>  6.45947303   0.13593172
> (0.89052006) (0.01948648)
>> ## now do this directly with more control.
>> fitdistr(x, dgamma, list(shape = 1, rate = 0.1), lower = 0.01)
>     shape         rate
>  6.48714685   0.13651706
> (0.89442924) (0.01956916)
>
> So it was perhaps lucky that I did not run update.packages yesterday,
> since I would have expected that (like PR#1717) my bug report would be
> filed under not-reproducible. :-)
>
> But this made me curious, and I fired my laptop (which has an Intel
> chip) up under Windows (usually it runs under Linux) and installed R
> 2.1.1 on it.  On that Windows machine, I get the same answers as those
> reported yesterday under both MASS 7.2-16 and 7.2-18.  Thus, I am a
> bit baffled.  Well, I just went back to the AMD box and re-run the
> code, now it gives me again the "nonsense" answer in the second case.
> There is definitely something wrong in the L-BFGS-B routine, which
> will be hard to find.
>
> Regarding the changed subject line:
>
> After installing R 2.1.1 on my laptop, I executed an R source file
> which, essentially, only contains an install.packages command with the
> list of contributed packages that I like to have installed.  One of
> this packages is DAAG and it seems that overnight the file
> DAAG_0.58.zip disappeared from
>        http://mirror.aarnet.edu.au/pub/CRAN/bin/windows/contrib/2.1/
> so the install.packages command terminated with an error message that
> the source file could not be downloaded.
>
> Would it be possible to robustify the install.packages command such
> that it continues with installing all the other packages requested
> instead of terminating?
>
> After redirecting R 2.1.1 on my laptop to use
>        http://cran.au.r-project.org/
> for the CRAN repository, the install.packages() command ran without
> problems.  I issued the command `library(MASS)' and tried out the
> example from fitdistr on that machine (same strange result for second
> command and warning messages were issued).  So I said
> update.packages()  and that command failed when it wanted to update
> the MASS package.  So I detach()'ed MASS and re-ran update.packages()
> and again it failed.  So I exited R 2.1.1 and restarted it again
> (probably I should have unloaded the namespace of MASS??) and then the
> update.packages command worked.

Yes, and that *is* in the rw-FAQ.

> However, update.packages() wanted to update quite a few packages
> besides MASS (the other packages in the VR bundle, nlme, lattice &c).
> Once it failed on MASS, it terminated with an error and did not update
> any of the other packages.  Would it be possible to robustify
> update.packages behaviour such that it would continue in such
> situations with updating the remaining packages?

Not a good idea. Better to follow the FAQ.  At that point the dependencies 
have been worked out and will not be re-computed if a package installation 
fails.

-- 
Brian D. Ripley,                  ripley at 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 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595