Packaging Considerations for Non-Global Zones

When considering zones and packaging, two questions need to be answered:

• Does anything in my package have an interface that crosses the boundary between the global zone and non-global zones?

• How much of the package should be installed in the non-global zone?

Does the Package Cross the Global, Non-Global Zone Boundary?

If pkgA delivers both kernel and userland functionality, and both sides of that interface must be updated accordingly, then whenever pkgA is updated in a non-global zone, pkgA must also be updated in any other zones where pkgA is installed.

To ensure this update is done correctly, use a parent dependency in pkgA. If a single package delivers both sides of the interface, then a parent dependency on feature/package/dependency/self ensures that the global zone and the non-global zones contain the same version of the package, preventing version skew across the interface.

The parent dependency also ensures that if the package is in a non-global zone, then it is also present in the global zone.

If the interface spans multiple packages, then the package that contains the non-global zone side of the interface must contain a parent dependency on the package that delivers the global zone side of the interface. The parent dependency is also discussed in Dependency Types.

How Much of a Package Should Be Installed in a Non-Global Zone?

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:

1. 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

2. 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.