To make a clean build environment, you need to be able to detect the Linux vendor and make build settings based on this vendor. To help with this, many Linux vendors install a special file with the vendor name, or a special package with the vendor name. You can query for either of these.

For files, the convention follows:

/etc/vendor-release

For example:

$ more /etc/redhat-release

Red Hat Linux release 8.0 (Psyche)

For packages, the convention is vendor-release for a package name. For example:

$ rpm -q redhat-release

redhat-release-8.0-8

You can use either approach or simply define a macro for the vendor and use the --define option to set the macro. For example:

# rpmbuild –ba --define 'linuxVendor suse'

With this definition, you can use the macro %linuxVendor inside your spec files. It is generally easier, though, if your scripts can automatically detect the Linux vendor instead of having to define it manually. The manual approach works, though, if it becomes too much effort to detect the vendor automatically.

Once you can detect the Linux vendor, you can create macros based on the differences between Linux distributions that affect your applications.

Cross Reference

Chapter 21 covers RPM macros.

The macros that specifically help you with platform differences include the %if .. %endif conditional. You can use this in combination with special macros you define. In addition, command-line options such as --with, --without, and --target allow you to control features and the build target within an RPM.

The %if macro allows you to specify a condition within your spec file. For example:

%if %{old_5x} && %{old_6x}

%{error: You cannot build for .5x and .6x at the same time}

%quit

%endif

%if %{old_5x}

%define b5x 1

%undefine b6x

%endif

%if %{old_6x}

%define b6x 1

%undefine b5x

%endif

You can also use %if to control settings such as the Requires:, as shown in the following example:

%if %{build6x}

Requires: util-linux, pam >= 0.66-5

%else

Requires: util-linux, pam >= 0.75-37, /etc/pam.d/system-auth

%endif

The --with command-line option defines a special macro starting with _with_. For example, the following command-line option defines a feature to use:

$ rpmbuild –bc --with ssh filename.spec

This example defines the macro _with_ssh to --with-ssh. This format was specially designed to work with GNU configure. You can use this for conditional builds for platform-dependent issues.

The --without command-line option similarly defines a macro starting with _without_. The convention is that this option defines a feature the code should not use.

You can combine --with and --without to turn on and off features referenced in your spec files. For example:

./configure %{?_with_ssh}

This will pass the following command line if the _with_ssh macro is defined:

./configure --with-ssh

If this option is not defined, the command will be:

./configure

The --target option sets the spec file macros %_target, %_target_arch, and %_target_os . For example:

$ rpmbuild -bc --target ppc-ibm-aix /usr/src/redhat/SPECS/jikes.spec

Not all Linux distributions are the same. Macros alone won’t provide work-arounds for all the differences. You can, though, get a lot of mileage from compatibility and glue packages.

A compatibility package provides a legacy API on newer systems that no longer support the legacy API. By convention, compatibility packages are named with a leading compat- to signify their purpose.

For example:

$ rpm -q --qf "%{description}" compat-libstdc++

The compat-libstdc++ package contains compatibility Standard C++

Using a compatibility package allows you to create programs that use a least-common-denominator approach, programming to the oldest but most common APIs. As some Linux distributions eliminate the old APIs, compatibility packages can provide the missing APIs.

Similarly, a glue package provides a dependency that exists on some Linux distributions but not others. It glues together your package with the Linux distribution that is missing an essential capability.

Note

A key point in both of these approaches is to separate the compatibility and glue packages from your main application packages. The application packages should be as clean of vendor issues as possible. Instruct your users to install the compatibility or glue packages as needed (based on their Linux distribution) along with the main application package or packages.

With all this discussion of RPM and Linux differences, you might think that Linux is one big mess. That’s not true. Linux maintains a high degree of compatibility among Linux distributions as well as among processor architectures. Most programs originally created for Linux on Intel-based architectures compile cleanly on Linux versions running on other processor architectures such as MIPS, SPARC, and ARM.

The main differences lie in how Linux vendors split up the huge number of files associated with Linux into RPM packages as well as which versions of tools like C compilers the vendors ship.

With SUSE Linux, or any Linux based on UnitedLinux 1.0, the RPM packages are signed with OpenPGP version 4, not 3, as used in RPM 4.1. This means that you must use some other, non-RPM means to extract the signatures from an RPM package, and then verify these signatures with gpg.