From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: bug#22695: Binary Installation bugs and suggestions Date: Tue, 16 Feb 2016 14:04:52 -0500 Message-ID: <874md84gtn.fsf@gmail.com> References: <878u2k4oh5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVkvr-0003yQ-ND for bug-guix@gnu.org; Tue, 16 Feb 2016 14:05:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVkvm-00010F-MB for bug-guix@gnu.org; Tue, 16 Feb 2016 14:05:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:39708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVkvm-000108-JE for bug-guix@gnu.org; Tue, 16 Feb 2016 14:05:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aVkvm-0000ks-Cm for bug-guix@gnu.org; Tue, 16 Feb 2016 14:05:02 -0500 In-Reply-To: Sender: "Debbugs-submit" Resent-Message-ID: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVkvb-0003at-1X for bug-guix@gnu.org; Tue, 16 Feb 2016 14:04:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVkvW-0000xh-15 for bug-guix@gnu.org; Tue, 16 Feb 2016 14:04:50 -0500 Received: from plane.gmane.org ([80.91.229.3]:44068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVkvV-0000xd-PH for bug-guix@gnu.org; Tue, 16 Feb 2016 14:04:45 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aVkvT-0004Nl-Fr for bug-guix@gnu.org; Tue, 16 Feb 2016 20:04:43 +0100 Received: from c-73-167-118-254.hsd1.ma.comcast.net ([73.167.118.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Feb 2016 20:04:43 +0100 Received: from myglc2 by c-73-167-118-254.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Feb 2016 20:04:43 +0100 List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: 22695@debbugs.gnu.org Ricardo Wurmus writes: > myglc2 writes: > >> The use case I had in mind is that sysadmin uses Guix to provide a >> specific Guix environment to support 1 or more "dumb" application users >> (e.g, provide a stable specific version of R to a project team for the >> duration of the project). In this case sysadmin does not want to burden >> the team members with learning Guix. >> >> Do we support such a case? > > Yes. I have been doing this for our cluster users for months before we > could make the changes in our environment that were needed to let users > manage their profiles by themselves. > > We currently use Guix for shared per-group profiles, individual per-user > profiles, and per-project profiles. > > You can install packages into a custom profile by using the “-p” flag, > e.g. > > guix package -p /path/to/shared/profile \ > --install glibc-utf8-locales r r-genomation > > Users would then have to add something like this to their > ~/.bash_profile: > > eval $(guix package -p /path/to/shared/profile --search-paths=prefix) > > or just add the result of the command in parentheses to the > ~/.bash_profile. This would prepend the “bin” directory of the profile > to the PATH and set other environment variables that are needed. > > Then they could use an unchanging version of the “genomation” package > from within R, as defined in that profile. (In the long run it would > make more sense to instantiate profiles using manifest files.) Fantastic. You have just described one of the fantasy use cases that have propelled me to spend a few weeks learning first NixOS and now Guix. > Slightly off-topic: note that in this case installing R packages via > ‘install.packages(...)’ is discouraged. Some R packages link with > system libraries and unless you’re also adding the compiler toolchain to > your profile you would end up with binaries that are linked with the > system libc and thus cannot successfully be loaded by the R in your > profile, which is linked with libc from the Guix store. > > I suggest going full Guix instead of mixing ‘install.packages(...)’ with > Guix stuff. We have importers for CRAN and bioconductor, so packaging R > packages for Guix is usually really simple. (I’ve used the importer to > generate package expressions for all of CRAN, but since I’m not using > them all I haven’t yet found motivation to submit patches for them.) I have bite marks from the same dog. I agree this is the way to go. >>>> 4) What do we mean by, 'The guix package must remain available in root’s >>>> profile, or it would become subject to garbage collection—in which >>>> case you would find yourself badly handicapped by the lack of the >>>> guix command.' >>>> >>>> What does root have to do to assure that 'The guix package remains >>>> available'? >>> >>> I think this means that the root user should not uninstall guix with >>> guix. >> >> "Thompson, David" writes: >> [...] >>> >>> Don't run 'guix package -r guix'. >> >> Cool, please say that. > > +1! > >> Ricardo Wurmus writes: >> [...] >>>> 5) We should tell root how to verify that the installation was >>>> successful. If 'make guix-binary.system.tar.xz' is intended to do >>>> this, we need to explain where to run it and how to verify the >>>> result. >>> >>> The install was successful if “guix package -i hello” (or similar) >>> works. >> >> Cool, lets tell them to do that. > > +1! > > Would you be willing to send a patch? (I’m pretty sure I’ll forget > doing this myself.) Will do once I get my Guix space suit fully inflated ;=)