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


1.  IPS Design Goals, Concepts, and Terminology

2.  Packaging Software With IPS

Designing a Package

Creating and Publishing a Package

Generate a Package Manifest

Add Necessary Metadata to the Generated Manifest

Evaluate Dependencies

Generate Package Dependencies

Resolve Package Dependencies

Add Any Facets or Actuators That Are Needed

Verify the Package

Publish the Package

Publish to a Local File Repository

Publish as a Package Archive

Using Package Repositories and Archives

Test the Package

Converting SVR4 Packages To IPS Packages

Generate an IPS Package Manifest from a SVR4 Package

Verify the Converted Package

Other Package Conversion Considerations

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

11.  Modifying Published Packages

A.  Classifying Packages

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

Converting SVR4 Packages To IPS Packages

This section shows an example of converting a SVR4 package to an IPS package and highlights areas that might need special attention.

To convert a SVR4 package to an IPS package, follow the same steps described in above in this chapter for packaging any software in IPS. Most of these steps are the same for conversion from SVR4 to IPS packages and are not explained again in this section. This section describes the steps that are different when converting a package rather than creating a new package.

Generate an IPS Package Manifest from a SVR4 Package

The source argument of the pkgsend generate command can be a SVR4 package. See the pkgsend(1) man page for a complete list of supported sources. When source is a SVR4 package, pkgsend generate uses the pkgmap(4) file in that SVR4 package, rather than the directory inside the package that contains the files delivered.

While scanning the prototype file, the pkgsend utility also looks for entries that could cause problems when converting the package to IPS. The pkgsend utility reports those problems and prints the generated manifest.

The example SVR4 package used in this section has the following pkginfo(4) file:

VENDOR=My Software Inc.
HOTLINE=Please contact your local service provider
DESC=A sample SVR4 package of My Sample Package
NAME=My Sample Package
CLASSES=none manpage
MSFT_DATA=Some extra package metadata

The example SVR4 package used in this section has the following corresponding prototype(4) file:

i pkginfo
i copyright
i postinstall
d none opt 0755 root bin
d none opt/mysoftware 0755 root bin
d none opt/mysoftware/lib 0755 root bin
f none opt/mysoftware/lib/ 0644 root bin
d none opt/mysoftware/bin 0755 root bin
f none opt/mysoftware/bin/mycmd 0755 root bin
d none opt/mysoftware/man 0755 root bin
d none opt/mysoftware/man/man1 0755 root bin
f none opt/mysoftware/man/man1/mycmd.1 0644 root bin

Running the pkgsend generate command on the SVR4 package built using these files generates the following IPS manifest:

$ pkgsend generate ./MSFTmypkg | pkgfmt
pkgsend generate: ERROR: script present in MSFTmypkg: postinstall

set name=pkg.summary value="My Sample Package"
set name=pkg.description value="A sample SVR4 package of My Sample Package"
set name=pkg.send.convert.msft-data value="Some extra package metadata"
dir path=opt owner=root group=bin mode=0755
dir path=opt/mysoftware owner=root group=bin mode=0755
dir path=opt/mysoftware/bin owner=root group=bin mode=0755
file reloc/opt/mysoftware/bin/mycmd path=opt/mysoftware/bin/mycmd owner=root \
    group=bin mode=0755
dir path=opt/mysoftware/lib owner=root group=bin mode=0755
file reloc/opt/mysoftware/lib/ path=opt/mysoftware/lib/ \
    owner=root group=bin mode=0644
dir path=opt/mysoftware/man owner=root group=bin mode=0755
dir path=opt/mysoftware/man/man1 owner=root group=bin mode=0755
file reloc/opt/mysoftware/man/man1/mycmd.1 \
    path=opt/mysoftware/man/man1/mycmd.1 owner=root group=bin mode=0644
legacy pkg=MSFTmypkg arch=i386 category=system \
    desc="A sample SVR4 package of My Sample Package" \
    hotline="Please contact your local service provider" \
    name="My Sample Package" vendor="My Software Inc." \
license install/copyright license=MSFTmypkg.copyright

Note the following points regarding the pkgsend generate output:

The following check shows the error message and the non-zero return code from pkgsend generate:

$ pkgsend generate MSFTmypkg > /dev/null
pkgsend generate: ERROR: script present in MSFTmypkg: postinstall
$ echo $?

The SVR4 package is using a postinstall script that cannot be converted directly to an IPS equivalent. The script must be manually inspected.

The postinstall script in the package has the following content:

catman -M /opt/mysoftware/man

You can achieve the same results as this script by using a restart_fmri actuator that points to an existing SMF service, svc:/application/man-index:default, as described in Add Any Facets or Actuators That Are Needed. See Chapter 7, Automating System Change as Part of Package Installation for a thorough discussion of actuators.

The pkgsend generate command also checks for the presence of class-action scripts and produces error messages that indicate which scripts should be examined.

In any conversion of a SVR4 package to an IPS package, the needed functionality probably can be implemented by using an existing action type or SMF service. See Package Content: Actions for details about available action types. See Chapter 7, Automating System Change as Part of Package Installation for information about SMF and package actions.

Adding package metadata and resolving dependencies are done in the same way as described in Creating and Publishing a Package and therefore are not discussed in this section. The next package creation step that might present unique issues for converted packages is the verification step.

Verify the Converted Package

A common source of errors when converting SVR4 packages is mismatched attributes between directories delivered in the SVR4 package and the same directories delivered by IPS packages.

In the SVR4 package in this example, the directory action for /opt in the sample manifest has different attributes than the attributes defined for this directory by the system packages.

The Directory Actions section stated that all reference-counted actions must have the same attributes. When trying to install the version of mypkg that has been generated so far, the following error occurs:

# pkg install mypkg
Creating Plan /
pkg install: The requested change to the system attempts to install multiple actions
for dir 'opt' with conflicting attributes:

    1 package delivers 'dir group=bin mode=0755 owner=root path=opt':
    3 packages deliver 'dir group=sys mode=0755 owner=root path=opt':

These packages may not be installed together. Any non-conflicting set may
be, or the packages must be corrected before they can be installed.

To catch the error before publishing the package, rather than at install time, use the pkglint(1) command with a reference repository, as shown in the following example:

$ pkglint -c ./cache -r file:///scratch/solaris-repo ./
Lint engine setup...

PHASE                                          ITEMS
4                                          4292/4292
Starting lint run...

ERROR pkglint.dupaction007        path opt is reference-counted but has different attributes across 5
duplicates: group: bin -> mypkg group: sys -> developer/build/onbld system/core-os system/ldoms/ldomsmanager

Notice the error message about path opt having different attributes in different packages.

The extra ldomsmanager package that pkglint reports is in the reference package repository, but is not installed on the test system. The ldomsmanager package is not listed in the error reported previously by pkg install because that package is not installed.

Other Package Conversion Considerations

While it is possible to install SVR4 packages directly on an Oracle Solaris 11 system, you should create IPS packages instead. Installing SVR4 packages is an interim solution.

Apart from the legacy action described in Legacy Actions, no links exist between the two packaging systems, and SVR4 and IPS packages do not reference package metadata from each other.

IPS has commands such as pkg verify that can determine whether packaged content has been installed correctly. However, errors can result if another packaging system legitimately installs packages or runs install scripts that modify directories or files installed by IPS packages.

The IPS pkg fix and pkg revert commands can overwrite files delivered by SVR4 packages as well as by IPS packages, potentially causing the packaged applications to malfunction.

Commands such as pkg install, which normally check for duplicate actions and common attributes on reference-counted actions, might fail to detect potential errors when files from a different packaging system conflict.

With these potential errors in mind, and given the comprehensive package development tool chain in IPS, developing IPS packages instead of SVR4 packages is recommended for Oracle Solaris 11.