From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roel Janssen Subject: Re: [PATCH] gnu: r: Update to 3.3.1. Date: Sun, 31 Jul 2016 19:34:13 +0200 Message-ID: <87h9b5emp6.fsf@gnu.org> References: <874m77gpll.fsf@gnu.org> <8660rmgbgh.fsf@gmail.com> <20160731040956.GA22271@thebird.nl> <86d1ltloiu.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTucZ-0006lN-V0 for guix-devel@gnu.org; Sun, 31 Jul 2016 13:33:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTucW-000099-MA for guix-devel@gnu.org; Sun, 31 Jul 2016 13:33:51 -0400 In-reply-to: <86d1ltloiu.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 myglc2 writes: > 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"? I think Pjotr means environment variables. > How does one "make sure it does not get GC'd"? Keep it in a profile linked to the store. (So once you've installed a version in a profile, Guix will not GC it as long as you haven't removed the profile, or the programs in the profiles and its accompanying generations). > What happens when a user wants something else (e.g., not R) updated? He can just to `guix package --upgrade='. >> 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. I agree. However, when upgrading packages, they can be careful not to upgrade a package. You can do that by `guix package --upgrade --do-not-upgrade=r'. This may seem too difficult as well, but let's consider the alternative: Not upgrading packages upstream. That's what we can already do downstream (simply don't run `guix pull'). I like having the latest versions available in GNU Guix, and when I need an older version, I can find it in the version control system. Kind regards, Roel Janssen