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

----- Original Message -----

From: "Martin Morgan" <mtmorgan at fhcrc.org>
To: bioc-devel at r-project.org
Sent: Wednesday, May 7, 2014 10:07:10 PM
Subject: Re: [Bioc-devel] Tracking Current release (http://www.bioconductor.org/packages/current redirect to
http://www.bioconductor.org/packages/2.14)

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

This is automatically generated, as is
http://bioconductor.org/js/versions.js
which also includes the devel version number.

Dan

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