9.4 Installation Practice

Knowing how to build and install software is good, but knowing when and where to install your own packages is what proves to be useful. Linux distributions try to cram in as much software as possible on installation. You should always ask yourself if you should install a package by yourself instead.

Here are the advantages of doing it yourself:

You can customize package defaults.
Custom software usually survives operating system upgrades.
When installing a package, you often get a much clearer picture of how to use the package.
You always get the latest releases.
It's easier to back up a custom package.
It's easier to distribute self-installed packages across a network.

These are the disadvantages:

It takes time.
If you don't actually use the package, you're wasting your time.
There is a potential for misconfiguring packages.

Consider the C library and the coreutils package ( ls , cat , and so on) ” there really is no point in building these by yourself unless you have some real obsession with the build process. On the other hand, if you have a vital interest in network servers such as Apache, the best way to get complete control is to install the servers yourself.

9.4.1 Where to Install

The default prefix in GNU autoconf and many other packages is /usr/local , the traditional directory for locally installed software. Operating system upgrades ignore /usr/local , so you won't lose anything installed there during an operating system upgrade.

For small local software installations, /usr/local is fine. However, if you have a lot of custom software installed, this can turn into a terrible mess. Thousands of odd little files can make their way into the /usr/local hierarchy, and you may have no idea where the files came from.

There are several schemes that help manage software packages. I like the Encap system (http://www.encap.org/) because it requires no extra software.

Encap

Encap abuses symbolic links, but that's a small price to pay for the features you get:

You can identify everything in /usr/local by package name .
You can keep old versions of a software package intact, so you can always downgrade, run the old version, and or use the old version as a model.
It is easy to remove old versions and entire packages.
You can easily transport packages to another partition or another machine.
Encap requires very little extra configuration.

The main idea behind Encap is that you encapsulate a package installation before making it available in /usr/local . To start, you must have a common installation root (most administrators use /usr/local/encap or /opt ; this book uses /opt because it's shorter).

Let's say that you are installing bogon-3.2.3 . Here's what you would do with Encap:

Configure, build, and install the package with an installation prefix that reflects the package and version. For example, the package uses GNU autoconf, so run this command:
```
 ./configure --prefix=/opt/bogon/bogon-3.2.3 
```
Go to /opt/bogon and make a symbolic link to the install you just made from default :
```
 cd /opt/bogon ln -s /opt/bogon/bogon-3.2.3 default 
```
If there are binary programs in /opt/bogon/default/bin , run this command:
```
 ln -s /opt/bogon/default/bin/* /usr/local/bin 
```
If there are binary programs in /opt/bogon/default/sbin , run this command:
```
 ln -s /opt/bogon/default/sbin/* /usr/local/sbin 
```
Run the appropriate variant of the following command for each section in which there are manual pages (the example works for man section 1):
```
 ln -s /opt/bogon/default/man/man1/* /usr/local/man/man1 
```

Now the bogon package binaries and manual pages are available in /usr/local via symbolic links. Furthermore, you can now do the following:

If you ever need to know the originating package of an item in /usr/local/bin , you need only run ls -l on the link to see where it points.
To remove a package, you can remove the symbolic links and its directory in /opt . For example, to remove the bogon symbolic links in /usr/local/bin , run this:
```
 cd /opt/bogon/default/bin for file in *; do   rm -f /usr/local/bin/$file done 
```

Should You Compile Shared Libraries?

Shared libraries (see Section 8.1.4) cause trouble with custom installations, primarily because a shared library upgrade can break a large number of programs at once. For this reason, you should never make links to shared libraries in /usr/local/lib when using Encap. Leave shared libraries in their installed location.

Even with this precaution, you still have these problems:

It's hard to tell if you can actually delete an old shared library, because some program may depend on the library.
It's difficult to link programs against the shared library. You must use the -Wl,-rpath= path linker option.
When linking against a shared library, you should specify a path that includes a version number. For example, use /opt/bogon/bogon-3.2.3/lib instead of /opt/bogon/default . You risk library version mismatches otherwise .

In fact, shared libraries can cause so many problems that you should always think twice before installing them. If the library is fairly small (such as libpng and libtiff ), there's no problem in opting for static libraries over shared libraries. Use this configure option to disable shared libraries for packages that use GNU autoconf:

 ./configure --disable-shared

Encap, pkg-config , and Shared Libraries

You can't get away with static libraries for everything. Enormous libraries such as GNOME components demand shared libraries. In the worst cases, you need to slug it out with LDFLAGS Makefile and environment variables . Happily, many larger libraries also use pkg-config , described in Section 9.3.3.

You can make Encap work with pkg-config if you put in a little extra effort. To set it up, you need to know which lib/pkgconfig directory pkg-config searches for .pc files. Let's say that you're trying to install the shared libraries from bogon-3.2.3 with Encap:

Configure, compile, and install the package as usual.
Carry out the Encap steps discussed earlier. In particular, you need the default symbolic link to point to bogon-3.2.3 .
Go to /opt/bogon/default/lib/pkgconfig . You should see a file named bogon.pc .
Edit bogon.pc . Look for this line:
```
 Libs: -L${libdir} -lbogon 
```
Change that line to reflect a runtime link path:
```
 Libs: -Wl,-rpath=${libdir} -L${libdir} -lbogon 
```
Now tell pkg-config about the package. If pcpath is where pkg-config keeps its .pc files (for example, pcpath could be /usr/local/lib/pkgconfig ), create a symbolic link:
```
 ln -s /opt/bogon/default/lib/pkgconfig  pcpath  
```
Test pkg-config on bogon :
```
 pkg-config --libs bogon 
```

The output should include -Wl,-rpath .