From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: bug#22695: Binary Installation bugs and suggestions Date: Tue, 16 Feb 2016 18:32:28 +0100 Message-ID: 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]:34929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVjUs-0005Jl-Au for bug-guix@gnu.org; Tue, 16 Feb 2016 12:33:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVjUl-0005nz-4z for bug-guix@gnu.org; Tue, 16 Feb 2016 12:33:10 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:39633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVjUk-0005np-SR for bug-guix@gnu.org; Tue, 16 Feb 2016 12:33:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aVjUk-0005MW-HQ for bug-guix@gnu.org; Tue, 16 Feb 2016 12:33:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <878u2k4oh5.fsf@gmail.com> 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: myglc2 Cc: 22695@debbugs.gnu.org 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.) 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.) >>> 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.) >> Sysadmin here :) I installed it according to the instructions but also >> expanded on them by setting up a shared store. I’ll try to prepare an >> RPM to simplify installation on distributions derived from Red Hat / >> Fedora. > > Sorry, buy you really don't sound like 'a typical sysadmin'. Oh, well :) > In my experience, Mr. typical admin says, "if it's not in Yum or Aptitude I'm > not going there". > > A specific example, Mr. typical admin can not install the current > release of package A because it is not in the production yum for the > previous release of centos currently running. Mr. typical admin can not > build the package from sorce because it would 'take too much time' > and/or 'you are the only person asking for it'. Heh, I think I know (an instance of) that person (template)! I seem to remember that there’s an RPM for OpenSUSE somewhere, but I’m not sure what the status is. In my opinion it would be desirable to have the .spec file to generate the RPM in the Guix sources. ~~ Ricardo