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
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
