⁠Chapter 18. Using RPM on Non-Red Hat Linuxes

Red Hat Linux 8.0 ships with RPM version 4.1. Other distributions of Linux ship with other versions of RPM. Thus, one of the first commands you can run on another Linux distribution is the rpm --version command, to see what RPM version is in use and help identify any issues. For example:

$ rpm --version

RPM version 4.1

Once you know the RPM version, you can plan for any issues that arise from installing RPMs made with a different RPM version. For example, RPM 4.0 and higher inserts dependency information automatically into RPMs. If your Linux distribution runs RPM 3.x, you may need to disable some of the dependency checks, for example, if you want to install RPMs built under RPM 4.x onto an RPM 3.x system.

On installing RPMs, you can disable the dependency checks with the --nodeps option. If you do this, though, you should manually check that the dependencies are really met by your Linux installation.

On the other hand, if you want to install RPMs built on an RPM 3.x system onto an RPM 4.x system, you may need to deal with package signatures. RPM 4.x versions also automatically check for signatures. When installing packages on an RPM 4.x system, you can disable this feature with the --nosignature option.

Using these techniques, you should be able to install packages built with RPM 4.1 on systems that use RPM 3.x versions or vice versa.

There is no standardization as to how large applications are divided into packages on different Linux distributions. This means that dependencies between packages may differ.

If your dependencies are for packages provided with the Linux distribution, which includes a huge number of packages, you must address this issue. The package an RPM depends on may not exist and may not even be needed, on a particular Linux distribution.

If instead the dependencies are for files, especially shared libraries, you should be okay for the most part, unless the files are located in different directories.

The only real solution to this problem is to turn off dependency checks on installing, with the --nodeps option. Then you must check manually that your system really does provide all the necessary dependencies. Use the techniques shown in Chapter 5, Package Dependencies to verify all the dependencies are met on your system.

Warning

Using the --nodeps option can lead to problems with your RPM database, because you are installing packages by defeating the RPM system's safeguards for dependencies. Only use the --nodeps option if you are really sure the dependencies are met on your system, even if from a different package than expected.

One of the toughest areas to deal with is the problem of dependencies. This topic ranges from the very simple issue of installing a necessary package to complex issues of shared library versions or particular Perl modules.

Start with the simple case and make certain that you haven’t failed to install a necessary RPM that provides the right dependency. In most cases, you can download a vendor-specific package from your Linux vendor, such as www.suse.com for SUSE Linux. Most Linux vendors provide HTTP or FTP sites with a large set of packages created for their distributions. If such a distribution-specific package solves a dependency issue, this is the easiest way around the problem.

After you verify that you haven't simply omitted a necessary package, move on to other potential explanations. Another issue involves shared libraries and ELF, or Extended Linking Format, symbols. A package may require an older or newer version of a shared library. Applications that are tied to a particular version of a shared library can cause problems, since you may not want to install incompatible versions of a shared library.

If the dependency is for a system-shared library, such as the shared C library, you can often recompile the package (rebuild from a source RPM) to get the package to use the newer or older version of the system library. This is possible because most Linux applications don’t call on version-specific features of system shared libraries (some do, but most don’t). If the dependency is for an application-shared library, this is more serious, since there were likely API changes that could impact the application. Install the package owning the application-shared library and again, try to rebuild the package from the source RPM.

Cross Reference

You can use the rpm -qf command to query which package owns a given file. You can use the rpm -q --whatprovides command to query for which package provides a given capability. Chapter 5, Package Dependencies covers more on dependencies.

Some packages are considered developer packages. These usually depend on some base package. For example, the rpm-devel package depends on the rpm package. The rpm-python package depends on both the rpm package and the python package (at particular version numbers as well).

This naming scheme of a base package and base-devel is used for Red Hat Linux packages, but may not be used for other vendor packages. In any case, you can solve this type of dependency by finding the relevant base packages that the package you are trying to install depends on. Consult the manuals that come with your Linux distribution or browse the online RPM repositories to see what naming conventions are used for your Linux distribution.

Many packages depend on scripting language interpreters, such as Perl. Sometimes the dependency is based on scripts used in a package, such as install or trigger scripts. You can have problems arise with the locations of these scripting interpreters. Perl, for example, is usually installed in /usr/bin/perl on most Linux systems. Another common location is /usr/local/bin/perl. In addition, packages may depend on particular add-on modules, especially Perl modules. With most versions of Linux released in the last few years, you should be able to override a Perl dependency with the --nodeps option as long as you have Perl installed.

File paths may also cause problems. For example, a file that a package depends on may be in a different location or owned by a different package. For this case, you can try to find the package that owns the file and make sure that package is installed. If your Linux vendor provides a pre-built RPM database of all packages, such as the rpmdb-redhat package, you can query this database to find out which package owns the file for that version of Linux.

Linux vendors can install software anywhere. For example, some distributions place a lot of software under /opt instead of the more common /usr. From an RPM perspective, this is mostly an issue with file dependencies and the install location for packages. Evolving file system standards also help limit this issue.

You can attempt to relocate any package using the --badreloc option.

Cross Reference

Chapter 3, Using RPM covers the --badreloc option.

But, while the --badreloc option will relocate the files in a package, it will not modify the contents of those files. So, any file inside a package that references files and directory locations may not work properly, since it may have the old, invalid, paths.

The only real way around this problem is to edit any script files that come with the package and contain hard-coded paths. If the paths reside inside binary executables, you need to get a source RPM for the package, patch the sources and then create a new RPM.

When all of these techniques fail to install a package, you still have a fallback option. If you have the source RPM for a package, you can install the source RPM on the new system and then edit the spec file until you can rebuild a package that will install on your version of Linux.

For example, a set of Build Root Policy (brp) helper scripts are run at the end of the %install section in an RPM. These scripts perform tasks such as compressing man pages. The Mandrake brp scripts use bzip2 compression. Red Hat brp scripts use gzip compression. This is one case where rebuilding an RPM and then installing may work best.