[Rd] install.packages and dependency version checking

[Prof Brian Ripley]

I've started to implement checks for package versions on dependencies in 
install.packages().  However, this is revealing a number of 
problems/misconceptions.


(A) We do not check versions when loading namespaces, ahd the namespace 
registry does not contain version information.  So that for example 
(rtracklayer)

Depends: R (>= 2.7.0), Biobase, methods, RCurl
Imports: XML (>= 1.98-0), IRanges, Biostrings

will never check the version of namespace XML that is loaded, either 
already loaded or resulting from loading this package's namespace.  For 
this to be operational we would need to extend the syntax of the imports() 
and importsFrom() directive in a NAMESPACE file to allow version 
restrictions. I am not sure this is worth doing, as an alternative is to 
put the imported package in Depends.

The version dependence will in a future release cause an update of XML 
when rtracklayer is installed, if needed (and available).


(B) Things like (package stam)

Depends: R (>= 2.7.0), GO.db (>= 2.1.3), Biobase (>= 1.99.5), pamr (>=
         1.37.0), cluster (>= 1.11.10), annaffy (>= 1.11.5), methods (>=
         2.7.0), utils (>= 2.7.0)

are redundant: the versions of method and utils are always the same as 
that of R.

And there is no point in having a package in both Depends: and Imports:, 
as Biostrings has.


(C) There is no check on the version of a package suggested by Suggests:, 
unless the package itself provides one (and I found no instances).


(D) We can really only handle >= dependencies on package versions (but 
then I can see no other ops in use).  install.packages() will find the 
latest version available on the repositories, and we possibly need to 
check version requirements on the same dependency many times.  Given that 
BioC has a penchant for having version dependencies on unavailable 
versions (e.g. last week on IRanges (>= 1.1.7) with 1.1.4 available), we 
may be able to satisfy the requirements of some packages and not others. 
(In that case the strategy used is to install the latest available version 
if the one installed does not suffice for those we can satisfy, and report 
the problem(s).)


(E) One of the arguments that has been used to do this version checking at 
install time is to avoid installing packages that cannot work. It would be 
possible to extend the approach to do so, but I am going to leave that to 
those who advocated it.


The net effect of the current changes will be that if there is a 
dependence that is already installed but a later version is available and 
will help satisfy a >= dependence, it will be added to the list of 
packages to be installed.  As we have seen with Matrix this last week, 
that can have downsides in stopping previously functional packages 
working.

This is work in progress: there is no way to write a test suite that will 
encapsulate all the possible scenarios so weneed to get experience 
until 2.9.0 is released.  Please report any quirks to R-devel if they are 
completely reproducible (and preferably with the code change needed to fix 
them, since the chance of anyone else being able to reproduce them are 
fairly slim).

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