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 <cmmarus...@gmail.com> wrote: > Luther Thompson <luther...@gmail.com> 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