| 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 |
| 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 |
1. IPS Design Goals, Concepts, and Terminology
2. Packaging Software With IPS
Creating and Publishing a Package
Add Necessary Metadata to the Generated Manifest
Add Any Facets or Actuators That Are Needed
Publish to a Local File Repository
Using Package Repositories and Archives
3. Installing, Removing, and Updating Software Packages
4. Specifying Package Dependencies
6. Modifying Package Manifests Programmatically
7. Automating System Change as Part of Package Installation
8. Advanced Topics For Package Updating
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.
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 PKG=MSFTmypkg ARCH=i386 DESC=A sample SVR4 package of My Sample Package CATEGORY=system NAME=My Sample Package BASEDIR=/ VERSION=11.11,REV=2011.10.17.14.08 CLASSES=none manpage PSTAMP=linn20111017132525 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/mylib.so.1 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/mylib.so.1 path=opt/mysoftware/lib/mylib.so.1 \
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." \
version=11.11,REV=2011.10.17.14.08
license install/copyright license=MSFTmypkg.copyright
Note the following points regarding the pkgsend generate output:
The pkg.summary and pkg.description attributes were automatically created from data in the pkginfo file.
A set action was generated from the extra parameter in the pkginfo file. This set action is set beneath the pkg.send.convert.* namespace. Use pkgmogrify(1) transforms to convert such attributes to more appropriate attribute names.
A legacy action was generated from data in the pkginfo file.
A license action was generated that points to the copyright file used in the SVR4 package.
An error message was emitted regarding a scripting operation that cannot be converted.
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 $? 1
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:
#!/usr/bin/sh 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.
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':
pkg://mypublisher/mypkg@1.0,5.11-0:20111017T020042Z
3 packages deliver 'dir group=sys mode=0755 owner=root path=opt':
pkg://solaris/developer/build/onbld@0.5.11,5.11-0.175.0.0.0.1.0:20111012T010101Z
pkg://solaris/system/core-os@0.5.11,5.11-0.175.0.0.0.1.0:20111012T023456Z
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 ./mypkg.mf.res 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.
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.
|