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.
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.
BuildRoot
headerLPMtool'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.
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
.
BuildPreReq
to BuildRequires
RPM's “BuildPreReq” is an alias for “BuildRequires”. LPMtool recognizes only “BuildRequires”.
(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.
LPMtool's macros have slightly different names.
Specifically, references to
%name
,
%version
, and
%release
must be replaced with
%__name
,
%__version
, and
%__release
.
%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.
LPMtool does not use epochs.
%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.
%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.
$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
.
%clean
sectionlpbuild 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).