1. 21
    Building and Installing Software in $HOME ☶ unix nullprogram.com
    sebboh avatar via sebboh 1 year ago | cached | 13 comments

Wellons has put a lot more work into this than I did, though I enjoy what I believe to be the same benefits.

I guess I haven’t encountered the library issue yet.

I just set my PREFIX= to ~/bin/emacs.app, then after make install, I do something like cd ~/bin; find emacs.app -executable -exec ln -s {} \;.

The result is:

sebboh@namagiri:~$ ls -al ~/bin
total 196
drwxr-xr-x 1 sebboh sebboh  602 May  3 13:26 .
drwxr-xr-x 1 sebboh sebboh 1124 Jun 22 17:44 ..
lrwxrwxrwx 1 sebboh sebboh   27 May  3 13:26 acyclic -> ../graphviz.app/bin/acyclic
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 bcomps -> ../graphviz.app/bin/bcomps
lrwxrwxrwx 1 sebboh sebboh   20 May  3 13:26 bin -> ../graphviz.app/bin/
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 ccomps -> ../graphviz.app/bin/ccomps
lrwxrwxrwx 1 sebboh sebboh   25 May  3 13:26 circo -> ../graphviz.app/bin/circo
lrwxrwxrwx 1 sebboh sebboh   27 May  3 13:26 cluster -> ../graphviz.app/bin/cluster
lrwxrwxrwx 1 sebboh sebboh   28 May  3 13:26 dijkstra -> ../graphviz.app/bin/dijkstra
lrwxrwxrwx 1 sebboh sebboh   24 Aug  5  2016 dlc -> /home/sebboh/src/dlc/dlc
lrwxrwxrwx 1 sebboh sebboh   23 May  3 13:26 dot -> ../graphviz.app/bin/dot
lrwxrwxrwx 1 sebboh sebboh   27 May  3 13:26 dot2gxl -> ../graphviz.app/bin/dot2gxl
lrwxrwxrwx 1 sebboh sebboh   32 May  3 13:26 dot_builtins -> ../graphviz.app/bin/dot_builtins
lrwxrwxrwx 1 sebboh sebboh   25 May  3 13:26 dotty -> ../graphviz.app/bin/dotty
lrwxrwxrwx 1 sebboh sebboh   29 May  3 13:26 edgepaint -> ../graphviz.app/bin/edgepaint
lrwxrwxrwx 1 sebboh sebboh   19 Jul  8  2016 emacs -> emacs.app/bin/emacs
drwxr-xr-x 1 sebboh sebboh   36 Jul  8  2016 emacs.app
lrwxrwxrwx 1 sebboh sebboh   25 Jul  8  2016 emacsclient -> emacs.app/bin/emacsclient
lrwxrwxrwx 1 sebboh sebboh   23 May  3 13:26 fdp -> ../graphviz.app/bin/fdp
lrwxrwxrwx 1 sebboh sebboh   22 May  3 13:26 gc -> ../graphviz.app/bin/gc
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 gml2gv -> ../graphviz.app/bin/gml2gv
lrwxrwxrwx 1 sebboh sebboh   30 May  3 13:26 graphml2gv -> ../graphviz.app/bin/graphml2gv
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 gv2gml -> ../graphviz.app/bin/gv2gml
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 gv2gxl -> ../graphviz.app/bin/gv2gxl
lrwxrwxrwx 1 sebboh sebboh   27 May  3 13:26 gvcolor -> ../graphviz.app/bin/gvcolor
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 gvedit -> ../graphviz.app/bin/gvedit
lrwxrwxrwx 1 sebboh sebboh   25 May  3 13:26 gvgen -> ../graphviz.app/bin/gvgen
lrwxrwxrwx 1 sebboh sebboh   25 May  3 13:26 gvmap -> ../graphviz.app/bin/gvmap
lrwxrwxrwx 1 sebboh sebboh   28 May  3 13:26 gvmap.sh -> ../graphviz.app/bin/gvmap.sh
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 gvpack -> ../graphviz.app/bin/gvpack
lrwxrwxrwx 1 sebboh sebboh   24 May  3 13:26 gvpr -> ../graphviz.app/bin/gvpr
lrwxrwxrwx 1 sebboh sebboh   27 May  3 13:26 gxl2dot -> ../graphviz.app/bin/gxl2dot
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 gxl2gv -> ../graphviz.app/bin/gxl2gv
lrwxrwxrwx 1 sebboh sebboh   25 May  3 13:26 lefty -> ../graphviz.app/bin/lefty
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 lneato -> ../graphviz.app/bin/lneato
lrwxrwxrwx 1 sebboh sebboh   25 May  3 13:26 mm2gv -> ../graphviz.app/bin/mm2gv
lrwxrwxrwx 1 sebboh sebboh   27 Sep 12  2016 mr -> /home/sebboh/src/myrepos/mr
lrwxrwxrwx 1 sebboh sebboh   25 May  3 13:26 neato -> ../graphviz.app/bin/neato
lrwxrwxrwx 1 sebboh sebboh   23 May  3 13:26 nop -> ../graphviz.app/bin/nop
lrwxrwxrwx 1 sebboh sebboh   25 May  3 13:26 osage -> ../graphviz.app/bin/osage
lrwxrwxrwx 1 sebboh sebboh   29 May  3 13:26 patchwork -> ../graphviz.app/bin/patchwork
lrwxrwxrwx 1 sebboh sebboh   25 May  3 13:26 prune -> ../graphviz.app/bin/prune
-rwxr-xr-x 1 sebboh sebboh  223 Sep 12  2016 replify
lrwxrwxrwx 1 sebboh sebboh   17 Jul  6  2016 sbcl -> sbcl.app/bin/sbcl
drwxr-xr-x 1 sebboh sebboh   22 Jul  6  2016 sbcl.app
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 sccmap -> ../graphviz.app/bin/sccmap
lrwxrwxrwx 1 sebboh sebboh   24 May  3 13:26 sfdp -> ../graphviz.app/bin/sfdp
lrwxrwxrwx 1 sebboh sebboh   28 Apr 21 16:07 siv -> /home/sebboh/src/siv/src/siv
lrwxrwxrwx 1 sebboh sebboh   32 Jun  1  2016 stumpwm -> /home/hobbes/src/stumpwm/stumpwm
lrwxrwxrwx 1 sebboh sebboh   24 May  3 13:26 tred -> ../graphviz.app/bin/tred
lrwxrwxrwx 1 sebboh sebboh   25 May  3 13:26 twopi -> ../graphviz.app/bin/twopi
lrwxrwxrwx 1 sebboh sebboh   29 May  3 13:26 unflatten -> ../graphviz.app/bin/unflatten
lrwxrwxrwx 1 sebboh sebboh   26 May  3 13:26 vimdot -> ../graphviz.app/bin/vimdot

I thought that I’d version all the *.app directories, but in practice, this isn’t really needed, because I got more than one machine… Who cares if emacs is broken for a day or two on one of them?

  1.  

  2. 3
    ec avatar ec 1 year ago | link

    If you can have someone install Nix in multi-user mode, then everyone with permissions to connect to the daemon can build local environments. It’s nice to have user-local binaries, but I’m not sure I can think of a scenario where running code on someone else’s server is valuable enough to justify giving up package management.

    1. 3
      Screwtape avatar Screwtape 1 year ago | link

      On the sliding scale of “installing software locally”:

      1. run software straight from the build directory (doesn’t work for all software)
      2. make PREFIX=$HOME/.local install as described here
      3. Install the application to some subdirectory like ~/.local/stowables/theapplication-1.2.3 and use GNU Stow to symlink it into place
      4. Nix

      Also, answering this:

      Fortunately, Debian and Debian-derived systems, using a mechanism I haven’t yet figured out, discover home directory man pages automatically without any assistance.

      From the output of manpath --debug:

      path directory /home/st/.local/bin is not in the config file
but does have a ../man, man, ../share/man, or share/man subdirectory
adding /home/st/.local/share/man to manpath

      So basically it guesses based on $PATH.

      1. 2
        rkeene avatar rkeene 1 year ago | link

        AppFS ( http://appfs.rkeene.org/ ) solves this problem, and takes it further to include de-duplication, distribution, authentication, and local modifications.

        1. 1
          josuah avatar josuah 1 year ago | link

          Filesystems are powerful tools (like what we can see with plan9, 9p…) !

          Tanks for sharing, I like the idea.

        2. 2
          rtpg avatar rtpg 1 year ago | link

          A coworker once pointed out to me that one of the big dangers of putting programs in $HOME like this is that now a malicious program can easily replace your installation of node or ghc or whatever.

          I don’t know how worried I am about this, given that the attacker would already have to have home access. But something to think about

          If anything it’s proof that file systems aren’t a great abstraction for organizing code that needs to be executed

          1. 4
            spc476 avatar spc476 1 year ago | link

            A malicious program can do this by modifying $PATH in the appropriate startup shell script (you have audited the which command, right?).

            So what is the appropriate abstraction for organizing code that needs to be executed?

            1. 2
              jimdigriz avatar jimdigriz 1 year ago | link

              The problem is more that ideally a user should not have both write and execute permissions to a location, such as $HOME or /tmp.

              Under UNIX a noexec flag for the mount solves a lot of problems and since WinXP there has bee Software Restriction Policies (including by path) to get the same effect.

              The result, a lot of malicious simply stops working.

              1. 2
                fs111 avatar fs111 1 year ago | link

                I am a programmer, so mounting my $HOME with noexec renders my box useless. This is no solution.

                1. 2
                  jimdigriz avatar jimdigriz 1 year ago | link

                  …or you create a separate mountpoint for your code in; such as /usr/src or $HOME/stuff or whatever your preference is.

                  1. 2
                    Rovanion avatar Rovanion 1 year ago | link

                    But then we’re back to the original issue aren’t we?

                    1. 1
                      jimdigriz avatar jimdigriz 1 year ago | link

                      Yes.

                      Malicious software (for now) just pokes the common locations such as /tmp or $HOME and not search everywhere for possible write/exec points. Setting these locations up to stop this can only be a good thing.

                      Of course this is a kind of security by obscurity but it is free and not intrusive.

                    2. 1
                      josuah avatar josuah 1 year ago | link

                      Such as opt ? Is it what opt is for ?

              2. 1
                josuah avatar josuah 1 year ago | link

                I wrote a package installer script (BUILD) doing this, along with a service management script (SERVICE): http://github.com/josuah/etc

                Both are really not smart (70~80 lines). What they do could be done by hand…

                Setting up your own embedded system across all distros (including BSD if you enable procfs(5)) feels good!

                And indeed, bootstrapping gcc or clang is a pain (chaining compilation from older version to newer version up to the latest: the first one cannot compile the last one directly).