[Bioc-devel] Tracking Current release (http://www.bioconductor.org/packages/current redirect to http://www.bioconductor.org/packages/2.14)
mtmorgan at fhcrc.org
Thu May 8 07:07:10 CEST 2014
Hi Don --
On 05/07/2014 06:21 PM, Don Armstrong wrote:
> I maintain a collection of Debian packages of CRAN and BioC 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
(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
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,
> unless that's what CURRENT_R_DEVEL_VERSION <- "2.14.0" is supposed to
> 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
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
More information about the Bioc-devel