Re: How should I install non-guix software?

[Luther Thompson]

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 <address@hidden> wrote:
> Luther Thompson <address@hidden> 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