Home Index Changes Prefs Log in »
Packaging Project

Image Packaging System (IPS) Assessment

Image Packaging System (IPS) is an OpenSolaris project, and offers a new packaging and repository system for Solaris software. From the update center/cross-platform/middleware point of view, this could potentially be used across more than just Solaris. That is the intent of this evaluation: to determine how portable, extensible, and feasible it is to use IPS as a more generic packaging system across typical middleware platforms (e.g. Windows, Linux).

Project Indiana Overview

Indiana Project Homepage

Questions and comments on IPS should be directed to the pkg-discuss@opensolaris.org alias.

Getting and Using IPS

To try out IPS, grab a copy of the binary executables for your platform, and visit the IPS HOWTO for usage instructions.

  • Note a non-optimized copy of Python is included in the distributions for evaluation purposes.

Porting IPS to Non-OpenSolaris Platforms

To download the source, grab a copy of Mercurial, then:

hg clone ssh://anon@hg.opensolaris.org/hg/pkg/gate

If you are behind a corporate firewall, you will need to configure SSH to tunnel through it. See "Proxies" section in OpenSolaris' SCM Help Page

Python Integration

Since Python is a key tool used by IPS, the Update Center project has had to evaluate how Python will be supported across a wide range of OS platforms.

Key Requirements Comparison

The following table of requirements is a subset of the Complete UC Package Requirements . This subset consists of requirements that are unique to the middleware space as compared to requirements of an OS.

#TitleDescriptionPriorityIPS Meets?
Overall Requirements
Overall-1.1 Provide a multi-OS platform packaging approach to be used by SWI components for the following operating systems: Solaris, popular Linux distributions, Windows and select Unix platforms. Mac OS is also of interest to support.By default, components will be delivered in uniform, multi-OS platform package format.

Decision Tree for Multi-platform Packaging Direction (rationale for pursuing a multi-platform packaging direction)
P1 No
Overall-1.2 Ease the generation of OS-specific format packagesAs the need arises, components will also be delivered in OS-specific package formats in addition to the multi-platform packaging format identified by this project.P2 Maybe (by virtue of being simple, for example no scripting allowed)
Overall-2.1 Ability to install multiple, completely distinct installation images on the same OS instance.Including distinct package databases.P1 Yes
Overall-2.2 Ability to install and manage packages as non-OS system administratorsSee Multi-install strategy document for details.P1 Yes
Package Maintainer Requirements
PM-1.4 Specify dependencies on files not necessarily delivered by packagesFor example, specifying a dependency on a file expected to be delivered outside the product or in an OS.P1 No, is this really needed though?
PM-6.1 Generate OS-specific package formats at willThis is a requirement that could be satisfied over time.P2See Overall-1.2
Distribution Assembler Requirements
DA-1.1 Minimize size of bootstrap install imageSince the packaging and basic update technologies are expected to be used by relatively small-scale distributions. e.g. 10's of MB and upward, the size of the bootstrap install image must be relatively small. As a guideline, a maximum size of 5MB for the bootstrap image is desired. This target size excludes the size of a JRE if a JRE is required by the selected technology.P1Yes (could change depending on growth of IPS)
DA-1.2 Minimize external dependencies of bootstrap install imageDo not require administrators to install extra software apart from what is contained in the bootstrap install image in order to operate the basic package management and update tooling.P1Yes (assuming Python is bundled, which need not be installed onto the system by an admin)
DA-3.1 Easily create pre-installed and pre-configured images that can be transported to another compatible system and used immediately with no modifications to the package databaseTo the extent necessary, component configurations may need to be customized for the target host and network environment. However, this level of customization is outside the scope of the packaging system.P2Yes
Adminimstration Requirements
ADM-7.1 Copy an installed image from one system to anotherSimilar to DA-2.1. For example, as part of the process of promoting a tested installation from a development or test system to a pre-production staging system and eventually onto a production system. To the extent necessary, component configurations may need to be customized for the target host and network environment. However, this aspect of customization is outside the scope of the packaging system.P2Yes
ADM-8.1 Side-by-side installationsSupport frequent cases in which new versions of installations are intended to co-exist on the same OS instance.P1Yes
ADM-9.1 Help facilitate an in-place upgrade of an installationAn "in-place" upgrade is one in which at the end of the upgrade process the same installation path contained the upgraded installation. This results does not have to imply that each package is upgraded in place. The mechanism used to achieve this result might perform a backup of the current installation, install a new image and then upgrade the configurations.

The packaging infrastructure will likely play a supporting role for in-place upgrades, but the overall responsibility for orchestrating an in-place upgrade probably rests with higher-level tooling.
ADM-9.2 Help facilitate a side-by-side upgrade of an installationIn many cases administrators either do not trust an "in-place" upgrade procedure or wish to preserve their existing installation when installing a new version of an offering.P1Yes
ADM-9.3 Help facilitate rollback of install image-wide upgrade failureIn contrast to the removal of an individual update applied to a singular package, removal or rollback of an installation-wide upgrade is more involved and can span the entire depth of a dependency tree of a stack of components. It is clear that there is value in being able to return an installation image (and related configuration) back to the state prior to the failed upgrade. The exact mechanism employed here could vary from simply applying (and then removing) individual updates, in the appropriate dependency order, or employing some kind of transaction processing model, allowing entire upgrades to be performed before commit (and therefore not committing when a failure occurs). P?Maybe (TBD - it may not be supported on all platforms)
ADM-10.1 Easily determine installations available to an OS instanceConsult OS-specific installation or management tool to list installed images. For example, integration with Windows Add/Remove Programs. Perhaps visibility within a Linux or Unix package database for each installed image.P1Unclear
ADM-12.1 Carry out removal or update of an installed image from within the installed imageFor example, an "uninstall" executable should be easily found near the top of each installed image.P1N/A
ADM-12.2 Trigger removal or update of installed image using OS-specific installation toolFor example, click on installation image's Add/Remove Programs entry to launch a tool to be able to remove or update an installation imageP1N/A
ADM-12.3 Trigger removal or update of an installation image through desktop applications icon P1N/A

Y = Technology has feature(s) which directly map to this use case / requirement
H = Technology has feature(s) which indirectly help to meet this use case / requirement
N = Technology has no features which help meet this use case / requirement, but should
- = Technology is not expected to significantly help directly or indirectly in meeting this requirements

IPS-Specific requirements

These additional packaging-specific requirements have been generated during the investigationof IPS. They are in some cases more detailed versions of requirements found above, called out here and tailored to suit the known properties of IPS and its current evolution direction.

IPS-1.1 FootprintSmall client footprint, especially regarding Python dependency. In general, this should be less than 5mb total, preferably 3mb or less.
IPS-1.2 Package GroupingAbility to define groups of modules for easy management at the group level.
IPS-1.3 Catalog MetadataAbility to associate attributes/metadata (at least the current set used by GlassFish) with packages or package groups.
IPS-1.4 Extensible MetadataAbility to add new application-specific attributes as needed (e.g. extensible)
IPS-1.5 PortingAbility to be ported (or made available on) popular Linux, Windows distributions, with potentially reduced performance or feature sets (e.g. limited backout capability without ZFS). Included here is filesystem difference handling (e.g. symlinks on Windows?)
IPS-1.6 BackportingAbility to be ported (or made available on) to Solaris 9 and 10, with potentially reduced performance or feature sets (see IPS-1.5)
IPS-1.7 Extensible File TypesAbility to be recognize and deal with new file classes (e.g. WAR, EAR files) without resorting to pre/postinstall scripts.

Screenshot-Add-Remove Applications-1.png

IPS Intangibles

Approachability The technology may be more complex and possibly more difficult to grasp quickly than a simple zip-based format like NBM
Time-To-Market It is likely we could get a solution out the door more quickly with a simple solution (like NBMs). However, the timeframe for the OpenSolaris Binary Distro project (Indiana) is pretty short - i.e. March-April '08.
Short-term sun.com Infrastructure Setup Piggyback on sun.com-based repository establishment and entitlement integration that Indiana will require.
Common Client Tooling Requirements OpenSolaris and unbundled SWI middleware and open source distros share many of the same requirements for both GUI and CLI client side package management and update tooling.
Common Need for Package Install OperationsPackages delivered through both OpenSolaris and SWI commercial and open source distros are required in some cases to result in installation operations to hook the package content into the local system. These integration steps range from making items appear in the Start menu to components such as Perl modules being made available to the local Perl runtime environment.
Another Example of Solaris Innovation Being Applied to Non-Solaris Platforms IPS could be an example. Similar to the desire for ZFS and DTrace to be made available on non-Solaris platforms.
Long Term Ecosystem If IPS is successful there will be a healthy eco-system surrounding it providing knowledge, tools, infrastructure, etc.
Solaris Alignment Co-operating and aligning with a critical Solaris project eases adoption and reduces objections, and is right for Sun
Long Term View Five years from now it would look silly doing anything else without serious technical/scheduling reasons.

« Home Attachments Info Index Changes
This page (revision-11) was last changed on 23-Oct-07 14:56 PM, -0700 by Ckamps