From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: Re: [PATCH] gnu: r: Update to 3.3.1. Date: Sat, 30 Jul 2016 15:41:50 -0400 Message-ID: <8660rmgbgh.fsf@gmail.com> References: <874m77gpll.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTaAm-0004b5-NM for guix-devel@gnu.org; Sat, 30 Jul 2016 15:43:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTaAh-0006Lk-Uy for guix-devel@gnu.org; Sat, 30 Jul 2016 15:43:48 -0400 Received: from blaine.gmane.org ([80.91.229.8]:37700) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTaAh-0006KU-Nr for guix-devel@gnu.org; Sat, 30 Jul 2016 15:43:43 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bTaAa-0000EF-Kz for guix-devel@gnu.org; Sat, 30 Jul 2016 21:43:36 +0200 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org Roel Janssen writes: > Dear Guix, > > With the following patch I would like to update R to 3.3.1. I tested > with R packages I regularly use and everything seems to work just fine. > > Is it OK to upgrade? > > Kind regards, > Roel Janssen > > >>From e8cdef8b2f287d26c4a4a9a02a7277dc940ed667 Mon Sep 17 00:00:00 2001 > From: Roel Janssen > Date: Sat, 30 Jul 2016 16:33:17 +0200 > Subject: [PATCH] gnu: r: Update to 3.3.1. > > * gnu/packages/statistics.scm (r): Update to 3.3.1. > --- > gnu/packages/statistics.scm | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm > index 2365149..ee84ffe 100644 > --- a/gnu/packages/statistics.scm > +++ b/gnu/packages/statistics.scm > @@ -100,7 +100,7 @@ be output in text, PostScript, PDF or HTML.") > (define-public r > (package > (name "r") > - (version "3.3.0") > + (version "3.3.1") > (source (origin > (method url-fetch) > (uri (string-append "mirror://cran/src/base/R-" > @@ -108,7 +108,7 @@ be output in text, PostScript, PDF or HTML.") > version ".tar.gz")) > (sha256 > (base32 > - "1r0i0cqs3p0vrpiwq0zg5kbrmja9rmaijyzf9f23v6d5n5ab2mlj")))) > + "1qm9znh8akfy9fkzzi6f1vz2w1dd0chsr6qn7kw80lqzhgjrmi9x")))) > (build-system gnu-build-system) > (arguments > `(#:make-flags Hi Roel, In my experience, the typical bio project analysis goes on for 1-5 years. Meanwhile R and BioConductor releases take place. Unfortunately, I have seen new R/BioConductor versions break a package in use, make it unavailable, or modify an analysis result, thereby screwing up the analysis at the most inopportune time ;-( The workaround used by sysops where I work (hospital research lab) is to give notice of R upgrades and to make previous releases available for reference by ongoing projects. IMO, we should consider how the guix R recipe(s) might support a pattern of use like this. I can assure you that if our users do guix pull and invisibly get a new R release, their analyses will from time to time break. So we may want a simple way for them to back down to a previous release. So.. I am thinking it would make sense to keep previous versions of R in the recipe. What do others think? - George