15. Converting RPM specfiles

Most RPM specfiles can be converted to LPMtool's format with only minor changes:

Reorganize the build header section

RPM combines the overall application headers (such as BuildArch and BuildRequires) and the headers of the main package (such as Requires:) together. LPMtool requires application and package headers listed separately: the application headers before the first %package directive, and the main package's headers after.

LPMtool generally ignores most descriptive headers. LPMtool itself does not do anything with Summary or Group; these headers' values are simply recorded in each package's manifest, with no further action on LPMtool's part, except that they are also listed by the lpm -q -i command.


Descriptive headers that appear in the build header portion of the specfile will be added to every binary package's manifest. Headers that appear in the package declaration will be added only to its package's manifest.

The same header cannot appear in both the build header, and a package declaration.

Remove the BuildRoot header

LPMtool's package build script always uses an installation image (a BuildRoot in RPM's terminology). Furthermore, lpbuild selects the location of the installation image itself, and it does not need to be explicitly specified with a header.

An RPM build script that does not use a BuildRoot must be fixed so that it can use the provided one.

Convert source0 and source macros

RPM's source0 and source are equivalent aliases; in LPMtool they are distinct. Their usage must be made consistent within a single specfile.

Convert BuildPreReq to BuildRequires

RPM's BuildPreReq is an alias for BuildRequires. LPMtool recognizes only BuildRequires.

Remove references to (post), (pre), et al

RPM's Requires header can be optionally followed by (post), or (pre) (or several others suffixes) to indicate that the given resources are required only by the package's installation or uninstallation scripts. LPMtool makes no such distinction, and these suffixes must be removed.

Rename some macros

LPMtool's macros have slightly different names. Specifically, references to %name, %version, and %release must be replaced with %__name, %__version, and %__release.

Convert %description text to HTML

Remove the %description sections, and add equivalent HTML text to the corresponding LPMtool package declaration section. Although any HTML is technically valid, avoid using tables. lpm's basic HTML formatter understands only paragraph and line breaks.

Remove all references to epochs

LPMtool does not use epochs.

Rename %prep, %build, and %install

Rename these scripts to %begin, %begin compile, and %begin install. Other names can be used instead, and the build script can be subdivided into additional section, for flexibility.

Trim the %setup and %patch macros.

LPMtool's %setup and %patch macros have been streamlined, and they take only a limited number of options. Everything else (such as -q) must be removed.

Replace $RPM_BUILD_ROOT with $__installdir

rm -rf $__installdir is also not required - lpbuild takes care of it.

Although LPMtool equivalents also exist for other RPM environment variables, they should be replaced by equivalent native macros, such as %_docdir.

Remove the %clean section

lpbuild knows how to clean up after itself.

Remove unwanted symbolic links

LPMtool is more picky, and will complain - unlike RPM - about symbolic links in the installation image that are not declared in a file manifest. This will often be the case with libtool, because it installs symbolic links that do not need to be packaged (they will be recreated when the package's installation script runs ldconfig).

The unpackaged soft links must be removed. In most cases, %{__rm} -f $__installdir%{_libdir}/*.so.? will do the trick (an extra question mark will be needed to take care of libraries whose version numbers have grown to two digits long).