JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Packaging and Delivering Software With the Image Packaging System in Oracle Solaris 11.1     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  IPS Design Goals, Concepts, and Terminology

2.  Packaging Software With IPS

3.  Installing, Removing, and Updating Software Packages

4.  Specifying Package Dependencies

5.  Allowing Variations

6.  Modifying Package Manifests Programmatically

7.  Automating System Change as Part of Package Installation

8.  Advanced Topics For Package Updating

9.  Signing IPS Packages

10.  Handling Non-Global Zones

Packaging Considerations for Non-Global Zones

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

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

Troubleshooting Package Installations in Non-Global Zones

Packages that Have Parent Dependencies on Themselves

Packages that Do Not Have Parent Dependencies on Themselves

11.  Modifying Published Packages

A.  Classifying Packages

B.  How IPS Is Used To Package the Oracle Solaris OS

Packaging Considerations for Non-Global Zones

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

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.