Advanced Parameters
The parameters described in this page are parameters which enable advanced RPM features. Before using these parameters, it is highly recommended that you read Maximum RPM to gain an understanding of what these parameters do.
RPM Package Dependency Management
These parameters relate to the dependencies between RPM packages, not to the dependencies required to build the RPM package contents.
There are six RPM spec file tags related to dependency management:
providesdefines a virtual package which is provided by the package being builtrequiresidentifies a package that is required to be installed for the package being built to operate correctlyrequiresPreidentifies a package that is required to be installed for the pre-installation scriptlet of the package being built to operate correctly. Packages that are listed here are installed before the pre-installation scriptlet of the package being built is run. Corresponds to theRequires(pre)tag in the spec file.requiresPostidentifies a package that is required to be installed for the post-installation scriptlet of the package being built to operate correctly. Packages that are listed here are installed before the post-installation scriptlet of the package being built is run. Corresponds to theRequires(post)tag in the spec file.requiresPreunidentifies a package that is required to be installed for the pre-removal scriptlet of the package being built to operate correctly. Corresponds to theRequires(preun)tag in the spec file.conflictsidentifies a package which must not be installed if the package being built is installedrecommendsidentifies a package that should be installed together with the package being built; the user can decline it. Corresponds to theRecommendstag in the spec file.suggestsidentifies a package that may be useful together with the package being built. Corresponds to theSuggeststag in the spec file.supplementsidentifies a package for which the package being built is a useful addition, the reverse ofrecommends. Corresponds to theSupplementstag in the spec file.enhancesidentifies a package that the package being built enhances, the reverse ofsuggests. Corresponds to theEnhancestag in the spec file.
recommends, suggests, supplements and enhances are weak dependencies, which need RPM 4.12 or later; older versions of rpm ignore the tags. They are available from release 2.5.0.
All of these tags can appear multiple times in the spec file. To configure these tags in the plugin configuration, specify an element for each instance of the tag in the spec file; the content of the element is the exact text to be placed in the spec file. Please be careful to ensure that version comparison specifications such as < and > are properly specified in the XML file. Here is an example:
<provides>
<provide>dump</provide>
</provides>
<requires>
<require>trash-truck > 1.0</require>
</requires>
<requires>
<require>road</require>
</requires>
<requiresPre>
<require>excavator</require>
</requiresPre>
<requiresPost>
<require>bulldozer</require>
</requiresPost>
<requiresPreun>
<require>environment-util = 2.0</require>
</requiresPreun>
<conflicts>
<conflict>incinerator</conflict>
</conflicts>
<recommends>
<recommend>recycling-plant</recommend>
</recommends>
<suggests>
<suggest>crane</suggest>
</suggests>
<supplements>
<supplement>landfill</supplement>
</supplements>
<enhances>
<enhance>garage</enhance>
</enhances>
addDependencyBasedRequires
If you set the boolean property addDependencyBasedRequires to true, all Maven dependencies of type rpm in the current project will be added as a dependency to the generated RPM.
Using this option, you don't need to specify the requires option (see above) for the direct RPM dependencies that you specified in your pom.xml.
This option defaults to false.
RPM Build Dependency Management
These parameters relate to the dependencies required to build the RPM package contents.
There is one RPM spec file tag related to build dependency management:
buildRequiresidentifies a package that is required to be installed for the package being built to build correctly; i.e. it provides some tools needed during the building of the package, or some RPM macros that must be present when adding the scriptlets into the RPM package.
This tag can appear multiple times in the spec file. To configure this tag in the plugin configuration, specify an element for each instance of the tag in the spec file; the content of the element is the exact text to be placed in the spec file. Please be careful to ensure that version comparison specifications such as < and > are properly specified in the XML file. Here is an example:
<buildRequires>
<buildRequire>ruby > 1.8</buildRequire>
</buildRequires>
Relocation
If you specify the prefix/prefixes parameter to the RPM plugin, you can create a package that can be installed in a user-specified location. Before doing this, read and understand Maximum RPM Chapter 15 since there are a number of kinks and quirks that must be addressed.
Scripts
There are a number of scripts that can be included in the RPM package which are executed as part of the installation, removal, or verification of the package.
Each of the scripts can be configured as a Scriptlet, which allows the content of the script to be provided either as a String or as a file. If both parameters are specified for a script, the external file will be ignored. Before writing scripts for RPM packages, understand the script docs in Maximum RPM since the operation of the scripts must be done correctly or major problems can occur while installing or removing the package.
A <scriptFile> is an absolute path or a path relative to the project base directory. Since 2.5.0, a value that starts with classpath: names a resource on the plugin's class path instead, which lets you ship scripts in a jar that you add to the <dependencies> of the plugin. <fileEncoding> and <filter> apply to both forms.
Script files can be filtered by setting <filter> to true while inline scripts can be filtered together with the pom.
Here are examples of passing the content of the script in the pom (using <script>) and in a file (using <scriptFile>) and enabling filtering for preinstall.sh and classpath:preremove.sh scripts:
<prepareScriptlet>
<script>echo "preparing ${project.name}"</script>
</prepareScriptlet>
<preinstallScriptlet>
<scriptFile>/src/main/bin/preinstall.sh</scriptFile>
<fileEncoding>utf-8</fileEncoding>
<filter>true</filter>
</preinstallScriptlet>
<preremoveScriptlet>
<scriptFile>classpath:preremove.sh</scriptFile>
<filter>true</filter>
</preremoveScriptlet>
prepareScriptlet
This script specifies commands to prepare the build. It corresponds to the %prep tag in the spec file.
preinstallScriptlet
This script is run before the package is installed. It corresponds to the %pre tag in the spec file.
installScriptlet
This script is run as a part of installing the package. It corresponds to the %install tag in the spec file.
postinstallScriptlet
This script is run after the package is installed. It corresponds to the %post tag in the spec file.
preremoveScriptlet
This script is run before the package is removed. It corresponds to the %preun tag in the spec file.
postremoveScriptlet
This script is run after the package is removed. It corresponds to the %postun tag in the spec file.
verifyScriptlet
This script is run when the package is being verified. It corresponds to the %verifyScript tag in the spec file.
cleanScriptlet
This script is run after the package is installed to clean up installation files. It corresponds to the %clean tag in the spec file.
pretransScriptlet
This script is run at the beginning of the transaction. It corresponds to the %pretrans tag in the spec file.
posttransScriptlet
This script is run at the end of the transaction. It corresponds to the %posttrans tag in the spec file.
Triggers
Triggers are scripts which can be included in an RPM package to execute based on the action of other packages in a system. Before writing triggers for RPM packages, understand the triggers in the RPM documentation since the operation of the scripts must be done correctly or major problems can occur while installing or removing other packages.
Signatures
RPM packages may be signed using GPG or PGP. Currently the plugin only supports generating GPG signatures.
keyname
This parameter sets the name of the GPG key used to sign the package, and also turns on the signature. Setting this parameter is equivalent to defining the %_gpg_name macro and adding the --sign option to rpmbuild.
keyPassphrase
This parameter sets the passphrase for the key to sign the rpm. The use of this attribute requires expect to be available on the PATH.
keyExpectTimeout
This parameter sets how many seconds expect waits for each prompt while signing with a keyPassphrase. The default is -1, which means no timeout. It is available since 2.5.0.
signHashAlgorithm
This parameter sets the digest algorithm GPG uses to sign the package, for example SHA512. It defines the %_gpg_digest_algo macro, both when the package is signed with a keyPassphrase and when it is not. If it is not set, the GPG default applies. The user property is gpg.signHashAlgorithm. It is available since 2.5.0.


