InstallShield 11 Universal
InstallShield Universal includes complete support for the RPM Package Manager (RPM). RPM is a powerful command line-driven package management system that installs and uninstalls software while verifying, querying, and updating it on the machine. An RPM installation consists of an archive of files along with detailed information about the package itself, for example, its version, description, etc. RPM also includes its own APIs. (See the RPM Web site for detailed information about RPM.)
Although RPM provides a rich set of delivery functionality, prerequisites management, and stability through package integrity verification, it lacks the rich end-user experience and ease of use of the Universal installer and uninstaller engines. Therefore, we have combined these two technologies in the RPM Installer project type. This project type leverages the InstallShield Wizard user interface and tooling, and its application payload is deployed through RPM. This gives you increased value and a refined end user experience when targeting your Linux customers. In fact, you can successfully deploy this project type to any machine that has RPM installed.
The following information regarding Universal support for RPM is provided below:
You can build an RPM Installer project as a product that can be installed to a specific platform, or one that is installable on all machines that have RPM installed. You can also configure the RPM Build Configuration (in the Releases view) to include support for non-RPM machines so that the package can also be deployed to machines that do not have RPM installed by setting its Include Support for Non-RPM Platforms property to "True."
You can build an RPM Installer project as an RPM assembly. Assemblies can be defined as individual products, or they can be aggregated together to form more complex offerings such as suites. This methodology is prevalent in RPM, so there is a symmetry between Universal assemblies and RPM packages.
Built RPM assemblies can be deployed by several types of Universal projects that are built as products (see below). You can include them in Universal Installer and Dynamic Suite projects that also include references to non-RPM assemblies. Or, you can set the RPM Assembly Build Configuration's Include Support for Non-RPM Platforms property (in the Releases view) to "True" to include the ability to deploy the RPM assembly's payload to machines both with and without RPM installed. These options provide you with extreme flexibility in creating and deploying your software to all of your customers.
The payload of an RPM assembly can be delivered the following ways:
Requirements are supported by the Universal assembly architecture. By adding a reference to another RPM assembly to the product in an RPM Installer project, that product then requires that RPM assembly to either already be installed on the target machine or installed with the requiring product. This relationship is created and maintained in the Universal VPD.
The RPM Installer project also automatically adds the necessary information to maintain the dependency between the two embedded RPM packages in the assemblies. The project adds a string that represents the ProductName and Version to the Requires directive for the parent installer's embedded .rpm. This string is also added to the Provides directive of every built assembly so that when you build the assembly, it populates its Provides field with its own information.
You can also specify values in the Required property of the General Information view's RPM Properties to specify additional required relationships in the RPM database.
The RPM Installer project creates a relocatable RPM package by default. The predefined INSTALLDIR directory represents the installation location of the root product. This directory is automatically added to each new RPM Installer project and defined with a relocate value of $P(absoluteInstallLocation). You can also create additional relocatable directories, subdirectories under INSTALLDIR, and "absolute" directories—see Working With RPM Files and Folders/Setting Up the Directory Structure.
Regardless of the installation mechanism—running a Universal installer versus manually installing a generated .rpm file with RPM—the application payload is deployed in an identical fashion: files and directories are created in the same manner, and the package is registered in the RPM database. However, because we integrate RPM deployment into the Universal installer entity (the RPM assembly), there is some overhead added to the target machine that would not be present if RPM was used by itself. This overhead consists of the following:
RPM has no knowledge of the VPD Registry and Universal Product Uninstaller engine because they are not part of the embedded .rpm package, and they are not registered by RPM as part of the file payload for the application. Removing the application using just RPM would leave them on the target machine, as well as their describing information in the VPD Registry. Therefore, you have the option of allowing the end user to uninstall the package using rpm -e and having that RPM command execute the Universal uninstaller. This results in unregistration occuring in both the VPD and RPM registries. This property is set in the RPM Build Configuration/Advanced/RPM Erase property.
The RPM Installer project supports pre/post installation/uninstallation script execution using the %pre, %post, %preun, %postun sections in the .spec file. Editing these sections directly in the Universal interface is not supported. However, the Events view provides you with the same functionality using Java code. The Universal event methods that provide these capabilities are as follows:
Creating trigger sections in the .spec file is not supported.
Universal does not support subpackage creation. Signing the RPM package contained within the built assemblies is also not supported.
See Also
Determining the Project Type and Build Configuration to Use
Creating an RPM Project
Working With RPM Files and Folders
Building RPM Projects