[Bioc-devel] Tracking Current release (http://www.bioconductor.org/packages/current redirect to http://www.bioconductor.org/packages/2.14)

[Martin Morgan]

Hi Don --

On 05/07/2014 06:21 PM, Don Armstrong wrote:
> I maintain a collection of Debian packages of CRAN and BioC[1] for
> public use; currently, whenever BioC makes a new release, it requires
> manual intervention for me to point at the new release location.
>
> It would be helpful if there was a
> http://www.bioconductor.org/packages/current redirect to the current
> release, or if there was another easily parsable method to obtain the
> current bioC release version.

Bioconductor releases are tied to R versions and the 'current' Bioc for a 
particular R, in a brand new installation, is

   source("http://bioconductor.org/biocLite.R")
   biocVersion()

(this is BiocInstaller::biocVersion(), where the biocLite.R script has arranged, 
modulo MITM concerns below, to install the version of the BiocInstaller package 
relevant to your version of R). I personally think of this as the canonical 
location, but...

http://bioconductor.org/packages/release goes to the current release 
'biocViews', with packages under release/ being the current release versions. 
http://bioconductor.org/bioc-version is probably what you'll end up using 
(though I believe it's hand curated), and 
tools:::.BioC_version_associated_with_R_version (this is a function in R-3.1) 
gives the version that R thinks is the current BioC version (this can become 
stale, e.g., R-3.0.1 was released when BioC-2.12 was the current version, but 
part way through the R point release BioC 2.13 became available [or at least, 
that's how I remember it]).	

> FWICT, neither http://bioconductor.org/getBioC.R nor
> http://bioconductor.org/biocLite.R encode that information either,[2]
> unless that's what CURRENT_R_DEVEL_VERSION <- "2.14.0" is supposed to
> be.
>
>
> 1: http://debian-r.debian.net/
>
> 2: I should also point out that the current methodology of installing
> BioC using code from a remote host is problematic as it exposes users to
> MITM attacks because it is never checked for authenticity via PGP or at
> the very least, SSL. As such, sourcing that script and using variables
> populated by it isn't really acceptable.

Of course this is a valid concern and we can work toward a more secure approach.

Perhaps I could take the opportunity to ask a naive question about debian binary 
distributions of R. What is the directory into which packages are installed by 
sudo? In particular, are they unversioned, /usr/lib/R/library etc, as opposed to 
say /usr/lib/R-3.1/library ? I'm asking because a number of users seem to show 
up with say R-3.1 reporting a mix of R-3.1 and R-3.0.2 packages, usually to ill 
effect; this is not necessarily likely for user-installed packages, because the 
system directories won't be writeable and R will prompt with a versioned 
directory ~/R/x86_64-unknown-linux-gnu-library/3.1 as the location to install 
libraries. I'm wondering if mixed package versions would happen if their package 
manager failed to remove previously installed packages from the 
/usr/lib/R/library directory, or if the user installed multiple versions of R. 
Of course this could merely reflect users installing R without the help of 
package managers, and either way it might point to changes in the way R installs 
itself.

Martin

>


-- 
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793