From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luther Thompson Subject: Re: How should I install non-guix software? Date: Sun, 12 Aug 2018 20:53:35 -0400 Message-ID: <20180812205335.286582d7@gmail.com> References: <20180804214540.497af879@gmail.com> <871sbde7va.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fp17B-0001iV-Ds for help-guix@gnu.org; Sun, 12 Aug 2018 20:53:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fp176-0005A1-Gw for help-guix@gnu.org; Sun, 12 Aug 2018 20:53:45 -0400 Received: from mail-yw1-xc2f.google.com ([2607:f8b0:4864:20::c2f]:37872) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fp176-00059k-AV for help-guix@gnu.org; Sun, 12 Aug 2018 20:53:40 -0400 Received: by mail-yw1-xc2f.google.com with SMTP id w76-v6so12468167ywg.4 for ; Sun, 12 Aug 2018 17:53:39 -0700 (PDT) Received: from localhost (50-243-201-195-static.hfc.comcastbusiness.net. [50.243.201.195]) by smtp.gmail.com with ESMTPSA id k200-v6sm14868201ywe.1.2018.08.12.17.53.38 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 12 Aug 2018 17:53:38 -0700 (PDT) In-Reply-To: <871sbde7va.fsf@gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: help-guix@gnu.org Thank you for such a detailed response! Sorry it took me so long to get back to this. On Sat, 04 Aug 2018 21:48:41 -0700 Chris Marusich wrote: > Luther Thompson writes: > > If I have a source tarball for a program that doesn't have a Guix > > package, or if I write my own program, there just isn't any good > > place to put the installed files. Scripts have the additional > > problem of not being able to use their shebang line. > > I've sometimes created "/bin/bash" and "/usr/bin/env" on my system for > reasons like this. When using GuixSD, you can define these kinds of > files in your OS configuration using the special-files-service-type. > See "Base Services" in the manual for details [3]. I put `(extra-special-file "/usr/bin/env" (file-append coreutils "/bin/env"))` in my config.scm, and it worked perfectly. That will make things a lot easier. > > 1. Write a Guix package for every little piece of software we want > > to run. I have yet to successfully do this, but I might decide to > > learn someday. I already know Scheme. AFAIK, this won't work for > > node packages, but it should work for everything else. This > > solution would be a lot of work for users. > > In some ways, this is the best approach. However, I know it's easier > said than done. If you're ever feeling stuck, you can ask for help > here as long as the software you're trying to package is free > software. It's also helpful to look at the thousands of existing > examples in the Guix source tree, which are located in the > gnu/packages directory. So it looks like this is the best way to go. Thank you for clearing that up for me. > > 2. Put ~/bin in our $PATH and install all our executables there. > > This wouldn't work for the majority of software that installs more > > than just executable files. > > I'm not sure what you mean here. How would putting ~/bin in your > $PATH enable software that hard-codes a path of "/bin/bash" to find > the bash program? > > > 3. Instead of installing the software, run it directly from whatever > > directory we unpacked/compiled it to. > > Wouldn't this also fail to address the problem of hard-coded paths? Maybe I wasn't clear, but these points were only supposed to address where to place installed files. I addressed shebangs as a separate issue in the other 3 points. > > 1. Make a soft link at /usr/bin/env in the root filesystem pointing > > to /run/current-system/profile/bin/env. This seems like the simplest > > solution, but I figure there must be some reason the devs haven't > > already done this. > > In fact, if we added symlinks like "/bin/bash" to GuixSD by default, > it would mask certain kinds of packaging problems. If I packaged a > piece of software that uses the hard-coded path /bin/bash at runtime, > it would run fine on my system because I have a "/bin/bash" symlink, > which points to some (indeterminate) version of bash. When you > install the same package, your /bin/bash symlink might point to a > different version of bash, so the software might behave differently > for you than it does for me. In addition, if for example you make a > bundle of the software using "guix pack" and ship it to a system that > doesn't have /bin/bash, the software might break entirely. This does indeed explain why we can't have /usr/bin/env by default, but it kind of sucks that any user-friendly configuration will have to add it right back in. > Anyway, I hope that helps! Thanks for bearing with my very long > reply. It was very helpful. Thank you! > Footnotes: > [3] > https://www.gnu.org/software/guix/manual/en/html_node/Base-Services.html#index-special_002dfiles_002dservice_002dtype > Luther