statements. When Ignite-UX processes a large amount of impacts statements it can slow down to a significant degree.

Combining those large numbers of impacts statements down into a few that match planned mount points is a manual task (and, unfortunately, if the software ever changes you need to do it all again).

Impact Hints

∙Keep impact levels to the minimum required to minimize their affect Ignite-UX performance.

∙If you need detailed impacts, you can always summarize impacts into the most appropriate form (impacts based upon expected mount points) without having to have thousands of impacts statements.

Second, applications may require extra space. In the preceding application, what would you do if the application only installed a few MB into the file system /var/opt/application/data but then when configured needed the rest of the space?

You have to plan to have the space there when the application is installed. Sometimes you must manually change impacts statements to increase the impacts on a directory or directory structure because of space requirements on a file system that are not reflected in the size of the software to be installed.

An example of this might be database table spaces that may be required when an application creates a database at initial installation. If this occurs, manually changing impacts statements is the only way to account for the extra space required. Manually increasing the impacts in this case prevents anyone from decreasing the file system size to the point that failures occur.

Overstated SD impacts

There are conditions that can generate overstated impacts for SD based installs:

1. Overlapping bundles

You should be careful with bundles that contain overlapping contents. Ignite-UX only tracks impacts at the bundle level and cannot detect if bundles contain overlapping contents. If you select overlapping bundles (for example all of the Ignite-UX bundles) disk impacts may become overstated. This is, however, the way Ignite-UX was designed to work and is not considered a defect.

2. Impacts from patches

Most patches do not deliver new content. Apart from the patched files that may be saved, their impact on most file systems is only incremental. Prior to Ignite-UX version C.6.3 there was no way to tell Ignite-UX to ignore some of the impacts generated by patches. As of Ignite-UX version C.6.3 you can use the –doption with make_config to discount the space impacts by the percentage given (1-75 are the allowed values.) This will not discount the space that is assumed for files saved by the patch in /var/adm/sw/save, and you must test to ensure that the patches you are installing do not deliver large amounts of new files (as this may fill a file system during installation.)

Categories and other Ignite-UX software attributes

The instl_adm(4) manpage states the following about sw_category:

118