| LPMtool - LPMtool is a Package Management tool | ||
|---|---|---|
| <<< Previous | Chapter 7. Building packages | Next >>> |
Most RPM specfiles can be converted to LPMtool's format with only minor changes:
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.
| NOTE: | 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. |
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.
RPM's "source0" and "source" are equivalent aliases; in LPMtool they are distinct. Their usage must be made consistent within a single specfile.
RPM's "BuildPreReq" is an alias for "BuildRequires". LPMtool recognizes only "BuildRequires".
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.
LPMtool's macros have slightly different names. Specifically, references to %name, %version, and %release must be replaced with %__name, %__version, and %__release.
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.
LPMtool does not use epochs.
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.
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.
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.
lpbuild knows how to clean up after itself.
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).
| <<< Previous | Home | Next >>> |
| Multiple platform builds | Up | Publishing packages on a web site |