Determine Software Dependencies

After determining your software requirements, you can now begin investigating if the software that you deemed you no longer need is required by software that you do need. Linux has interdependencies among its different programs as Linux developers will often piggyback or reuse other software packages. These interdependencies can be confusing but are manageable if documented during your investigation. An example of the types of problems that can arise with software dependencies are with SLES8 and Samba-3. Samba-3 requires heimdal-0.6 to function properly. Updating SUSE s included version of heimdal-0.4e would require updating 30 or more system packages, and the total set of packages that must be updated to meet nested dependencies is 130 or more. This means it may be necessary to update to a later version of the OS to gain access to a particular software release or version. In the case of Samba-3, an outside entity provided Samba-3 packages that were statically linked with the newer version of heimdal allowing for the installation of Samba-3.

There are a few ways to determine what the dependencies are. The first is with the --whatrequires option. For example, to determine what packages require openssl capability, you can run the command as shown in Figure 4-8.

Figure 4-8: rpm -q --whatrequires command tree

It turns out there is a chain of dependencies for the openssl capability, so before removing that package, you must determine if you need the other packages shown as requiring openssl capabilities. In our example from SLES8, you know that kdebase3 requires openssl, so if you determine you don t need kdelibs (after running rpm -qi to get more information), you can see if anything requires kdelibs ”in this case, kdebase3. You would then decide if you need kdebase3 and if not, continue through the chain until you come to the end, which is shown by the no package requires kdebase3-SLOS2 statement.

This can be misleading, though, because these wouldn t be the only things that would need to be removed if you wanted to remove a package. It only shows what other packages depend on the named capability (in this case, the capability is openssl). A better way to get the most information is to use the following command, which gives more verbose information:

 rpm -e --test 

The -e option is to erase or remove the package, while --test will go through the process of removing the package showing any dependency errors, without actually trying to erase the package. Figure 4-9 shows the output from rpm -e --test openssl .

Figure 4-9: rpm -e --test output

After determining the dependencies, you will need to go through and determine which programs you will need before removing the main package. You might be tempted to use the --force option when removing packages, but this is not recommended because you could affect your software in unexpected ways. The time spent properly researching your system will save you significant time in troubleshooting and downtime in the future. If you are installing the system, always install the least amount of software required to provide the functionality needed for your organization s mission.

You should be aware that installing software on your system, even to satisfy dependencies for approved software distributed by the vendors (Red Hat and SUSE), can create support problems. By installing certain software you can void your support contract with the distributor. With the vast array of software available to users of Linux, the majority of which is free, there can be interdependency problems or conflict with other supported software. SUSE and Red Hat have to have a baseline of software to support, as it is not feasible or reasonable to expect them to support every software configuration available. SUSE and Red Hat have a specific set of software groups they support and because of this, you should read and understand your support contract to ensure that the software you are removing or installing does not void the contract or you could find yourself in an unsupported configuration, creating problems when there is a need for support.

An example of this is with the Samba packages provided by a major distribution. The packages wouldn t support a specific configuration required by a user, and a fix was readily available from the Samba team (it was a minor update, not a full upgrade of the software). The user contacted the distribution vendor to ensure that their software would be supported as this was a critical production server. The vendor stated that applying this minor upgrade would void the support contract and that if the update were installed, they could no longer support the customer if problems arose due to the software. This presented a problem for the user as they needed the functionality provided by the latest release of Samba or the previous version. The customer was forced to upgrade to the latest version and hope for the best until the newest version was supported. The moral of this story is to be careful when upgrading or installing software and always install in a test environment where production processes will not be affected.