There are four solutions to this problem:

∙Edit the apps_1203_cfg file and change the name of the sw_sel clauses so that they are unique and descriptive of the clause's content. This allows you to address the two software selection clauses uniquely. It also ensures that the intended software is selected from the core operating system (OE) depot, and that software from the applications media is not selected inadvertently. This is time consuming and if you want to update the configuration file using make_config you must reapply the changes.

∙Remove all of the software bundles that exist in the core operating system (OE) depot and the applications depot. You would run make_depots on the applications DVD then use swremove on the applications depot. HP does not recommend this solution.

∙Place the application media into the core operating system (OE) depot rather than putting it into a separate depot. This means that you must manage the depots as one. Note that you cannot update an OE in a depot. If you wish to use a new OE in an existing depot, you must remove the entire contents of the depot before using make_depots to copy in new software from OE and applications media. This also assumes that a different version of VxVM/VxFS is not available on the application media - you can’t cold install a different version of VxVM/VxFS to the version available from the core OE media.

∙Ensure that the Core OS (OE) media and applications media are always synchronized.

Follow on consequences

This can also lead to more serious problems when you have an application that depends on something that would normally be installed from the core OE depot, but because of the issues described above in “An example problem” it may be installed from somewhere else (the applications depot).

We will use the following cfg clause as the basis for our example:

cfg "HP-UX B.11.11" {

description "HP-UX 11.11 MCOE with vPars" "/opt/ignite/data/Rel_B.11.11/config" "/opt/ignite/data/Rel_B.11.11/hw_patches_cfg" "/var/opt/ignite/data/Rel_B.11.11/core_OE.cfg" "/var/opt/ignite/data/Rel_B.11.11/vPars_cfg" "/var/opt/ignite/data/Rel_B.11.11/apps.cfg" "/var/opt/ignite/config.local"

}

Some vPars filesets in version A.03.03.06 have an SD dependency on the fileset PartitionManager.PARMGR,r>=B.11.11.01.05. That means that the fileset PartitionManager.PARMGR of that revision or higher must be installed on the system otherwise parts of the vPars software won’t install83.

If the bundle that defines the Partition Manager commands is present in the core OE and the applications depot, it will be installed from the applications depot not from the OE depot. That means if the vPars software is installed after the OE depot but before the applications depot, the vPars software will only partially install because some dependencies cannot be met.

83If available from the same depot as the vPars software, it would be automatically selected but may only end up partially installed (since only the dependencies would be selected). If you didn’t keep the Partition Manager commands in sync with the application and core OE depots, you might end up with mixed revision filesets in the Partition Manager commands bundle.

178