From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: Re: [PATCH] gnu: r: Update to 3.3.1. Date: Sun, 31 Jul 2016 13:12:57 -0400 Message-ID: <86d1ltloiu.fsf@gmail.com> References: <874m77gpll.fsf@gnu.org> <8660rmgbgh.fsf@gmail.com> <20160731040956.GA22271@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTuKB-0002Sj-SG for guix-devel@gnu.org; Sun, 31 Jul 2016 13:14:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTuK7-00064Y-JX for guix-devel@gnu.org; Sun, 31 Jul 2016 13:14:50 -0400 Received: from blaine.gmane.org ([80.91.229.8]:56776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTuK7-00063y-CT for guix-devel@gnu.org; Sun, 31 Jul 2016 13:14:47 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bTuK0-0000Aj-9M for guix-devel@gnu.org; Sun, 31 Jul 2016 19:14:40 +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 Pjotr Prins writes: > 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? > 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. This functionality could be adequate in some situations if it can be made simple to use. Some questions to answer... What do you mean by "Unix modules"? How does one "make sure it does not get GC'd"? What happens when a user wants something else (e.g., not R) updated? > Another way to work it is by using a checked out Guix source tree. This is not simple and is beyond the capability of the medical researchers I have met. > 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 This comes the closet to being a "simple way for them to back down to a previous release". It has merit independent of R.