If all of a package should be installed when the package is being installed in a non-global zone, then nothing needs to be done to the package to enable it to function properly. For consumers of the package, though, it can be reassuring to see that the package author properly considered zone installation and decided that this package can function in a zone. For that reason, you should explicitly state that the package functions in both global and non-global zones. To do this, add the following action to the manifest:
set name=variant.opensolaris.zone value=global value=nonglobal
If no content in the package can be installed in a non-global zone (for example a package that only delivers kernel modules or drivers), then the package should specify that it cannot be installed in a non-global zone. To do this, add the following action to the manifest:
set name=variant.opensolaris.zone value=global
If some but not all of the content in the package can be installed in a non-global zone, then take the following steps:
Use the following set action to state that the package can be installed in both global and non-global zones:
set name=variant.opensolaris.zone value=global value=nonglobal
Identify the actions that are relevant only in the global zone or only in a non-global zone. Assign the following attribute to actions that are relevant only in the global zone:
variant.opensolaris.zone=global
Assign the following attribute to actions that are relevant only in a non-global zone:
zone:variant.opensolaris.zone=nonglobal
If a package has a parent dependency or has pieces that are different in global and non-global zones, test to ensure that the package works as expected in a non-global zone as well as in the global zone.
If the package has a parent dependency on itself, then the global zone must configure the repository that delivers the package as one of its origins. Install the package in the global zone first, and then in the non-global zone for testing.