QA /technical/2009/08/local-package-management-with-gnu-stow/

content/technical/2009/08/local-package-management-with-gnu-stow.html

@@ -1,11 +1,11 @@
 I'm a bit of a purist when it comes to installing UNIX style software. I prefer to install it via the package manager on the platform of choice (E.g. <a href="http://en.wikipedia.org/wiki/Advanced_Packaging_Tool">apt</a> on Debian or <a href="http://www.macports.org/">Mac Ports</a> on Mac OS X). However these repositories don't always contain the particular package you're after or may contain an outdated version.
 
-In situations like these where you end up building the package yourself I used to employ a system where I would install it into a subdirectory within my home directory. I did this because it doesn't overwrite a pre-existing system installed version, doesn't require root privileges and permits quick removal. To achieve this I just passed the <code>--prefix</code> option to the configure script before building. For example if I was building vala I might run the configure script as follows:
+In situations like these where you end up building the package yourself I used to employ a system where I would install it into a subdirectory within my home directory. I did this because it doesn't overwrite a pre-existing system installed version, doesn't require root privileges and permits quick removal. To achieve this I just passed the `--prefix` option to the configure script before building. For example if I was building vala I might run the configure script as follows:
 
-<pre>./configure --prefix=$HOME/Local/vala</pre>
+    ./configure --prefix=$HOME/Local/vala
 
-Following that with the typical <code>make</code>, <code>make install</code> sees the package built and installed into that directory. The problem with this approach is that for every package you build you have to add the target directory to search paths such as: <code>PATH</code>, <code>LD_LIBRARY_PATH</code>, <code>MANPATH</code>, <code>PKG_CONFIG_PATH</code>. After a while this gets a bit unwieldy. This is where <a href="http://www.gnu.org/software/stow/">GNU Stow</a> comes in.
+Following that with the typical `make`, `make install` sees the package built and installed into that directory. The problem with this approach is that for every package you build you have to add the target directory to search paths such as: `PATH`, `LD_LIBRARY_PATH`, `MANPATH`, `PKG_CONFIG_PATH`. After a while this gets a bit unwieldy. This is where <a href="http://www.gnu.org/software/stow/">GNU Stow</a> comes in.
 
-Stow manages these separate target directories by creating symlinks into the parent directories. For example to build vala I would pass a prefix of <code>$HOME/Local/stow/vala</code> to the configure script. After vala is built and installed, change to the <code>$HOME/Local/stow</code> directory and run <code>stow vala</code>. This results in symlinks to the files in <code>$HOME/Local/stow/vala</code> being created in <code>$HOME/Local</code>, with directory structure preserved. So if vala installs files to <code>bin</code> and <code>lib</code> these files will end up under <code>$HOME/Local/bin</code> and <code>$HOME/Local/lib</code> respectively.
+Stow manages these separate target directories by creating symlinks into the parent directories. For example to build vala I would pass a prefix of `$HOME/Local/stow/vala` to the configure script. After vala is built and installed, change to the `$HOME/Local/stow` directory and run `stow vala`. This results in symlinks to the files in `$HOME/Local/stow/vala` being created in `$HOME/Local`, with directory structure preserved. So if vala installs files to `bin` and `lib` these files will end up under `$HOME/Local/bin` and `$HOME/Local/lib` respectively.
 
 Stow can also delete the symlinks to support uninstalling. The end result is that you only need to add one extra directory to each of the search paths and custom software can be built, installed and uninstalled all without messing with the standard system and root privileges.