From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: [PATCH] gnu: r: Update to 3.3.1. Date: Sun, 31 Jul 2016 06:09:56 +0200 Message-ID: <20160731040956.GA22271@thebird.nl> References: <874m77gpll.fsf@gnu.org> <8660rmgbgh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTi4m-00044q-Uf for guix-devel@gnu.org; Sun, 31 Jul 2016 00:10:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTi4g-0003Mw-OH for guix-devel@gnu.org; Sun, 31 Jul 2016 00:10:07 -0400 Received: from mail.thebird.nl ([95.154.246.10]:40500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTi4g-0003Mk-IV for guix-devel@gnu.org; Sun, 31 Jul 2016 00:10:02 -0400 Content-Disposition: inline In-Reply-To: <8660rmgbgh.fsf@gmail.com> 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: myglc2 Cc: guix-devel@gnu.org On Sat, Jul 30, 2016 at 03:41:50PM -0400, myglc2 wrote: > 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? Hi George, If bioconductor tests pass on a new R build they *should* work. Guix is not the same mess that Debian and Fedora are. Note, meanwhile, that a new R install does not remove the old packages automatically. One way to work older versions is by using guix profiles effectively. We introduced Unix modules with Guix, so a module would point to a well tested and working profile. Just make sure it does not get GC'd at some point. Another way to work it is by using a checked out Guix source tree. That is what we do for Genenetwork deployment. Guix 'pull' simply represents a version of the source tree - with its combination of packages. You can force a combination of package versions by keeping track of your own tree. See https://github.com/genenetwork/genenetwork2/blob/master/doc/README.org In the near future I hope we get a version of guix pull which can essentially achieve the same (i.e. a checked out version of the tree). guix pull HASH-tag Pj.