Overall Positioning

Why did the Update Center 2 project select pkg(5)?

The project team had looked at a variety of packaging options to meet our needs before deciding to reuse the emerging Image Packaging System technology. Our main requirements were:

• Broad OS platform support (or at least relative ease in porting to multiple OS platforms)
• Ability to manage multiple distinct application installations on a single OS instance
• Ability to manage installations as non-root users

Additionally, many of the features of network-based packaging systems were also primary requirements for the Update Center 2 project.

None of the technologies we reviewed met these requirements out of the box. Linux-oriented technologies such as rpm and yum, dpkg and apt, while often available across multiple Linux distributions, aren't readily available on or easy to port to Windows and Mac OS X.

Since our developers had been funneling requirements to the OpenSolaris pkg(5) project since its earliest days, the three unique requirements listed above were designed into pkg(5) from the beginning.

Why is it called a "toolkit"?

The port of pkg(5) and delivery of complementary, multi-platform tools is delivered as a set of binaries and documentation that can be used by projects that are producing, delivering and supporting their own application distributions. These components make up the toolkit and are embedded in the application distributions and their associated package repositories. To date, other than for development and integration purposes, the toolkit is not distributed as a standalone product.

Can this port of of pkg(5) be used to package and maintain an Operating System?

No, not in its current form. The toolkit is oriented toward layered or unbundled applications that are installed on top of an OS. All testing and even the packaging of the toolkit concentrates on supporting "user images" - a feature of pkg(5) that enables self-contained installations to be managed independent of an OS' packaging system.

If you'd like to consider packaging and maintaining an OS using pkg(5), then you should consult with the pkg(5) project. This is the project that develops pkg(5) and helps to use it as the basis of the OpenSolaris OS distribution.

Updating and Patching

How do binary patches work with pkg(5)?

Similar to the popular Linux packaging systems such as rpm and deb, there is no binary patch per se in pkg(5). Fixes to binaries are delivered as package updates and are cumulative in nature for a specific sustaining tail of a package version.

Are updates delivered as sparse downloads?

Yes. Unlike some of the Linux packaging systems, the pkg(5) system delivers only the changed files when an installed package is being updated.

Will a modification of a small portion of a large file cause the whole file to be downloaded during an update?

Yes. Currently, the boundary is at the file level. In the future, pkg(5) may evolve to deliver only the modified portions of files. For example, if you are delivering an update to a 20MB WAR file, then the whole WAR file will be downloaded during any update of that file.

Package Installation Approaches

Is there an on-disk package format in pkg(5)?

No, not yet. The core pkg(5) project has RFE 2152 on their radar for a future release. This feature will eventually be available. Numerous parties are interested in it.

What if my deployment environment doesn't have access to the repositories?

Product distribution owners may provide archive forms of the repository content that can be used within a customer's closed network to run their own standalone instance of a repository.

Toolkit Packaging and Distribution

Are native packages of the toolkit available?

No. Currently, only zip archives of the toolkit bundles are available developers and adopting projects. Those bundles are pkg(5) user images that contain a subset of the toolkit packages in pre-installed form. If it was a priority for the Update Center project, we could wrap those user images in a variety of OS-specific package and install formats as a means of getting the user images expanded on user systems. The embedded user images would simply be payload in those native packages. Adopting projects may be more likely to do this because their audiences often expect some sort of initial install wrapper.

Adopting projects typically copy the toolkit packages of interest from the layered collection repository into their own repositories and optionally pre-install some or all of those toolkit packages into their own install bundles.

All of the toolkit's contents are packaged in pkg(5) format and are available from several repositories. The official source of promoted development packages is: http://pkg.sun.com/layered-collection/dev/

Update Tool GUI

Why isn't the Update Tool GUI written in Java?

Given the requirements to support a broad array of desktop environments, Swing was our first choice for a GUI framework when we began porting the Python-based pkg(5) system. However, at that time of initial development in early 2008 there was no cost effective means of integrating a Java Swing-based application with the Python-based pkg(5) system. Jython was looked at, but at the time it was not straightforward to effectively make use of a rich Python API from Java (Python to Java was more feasible). There were also practical realities to consider such as the version of Python required by pkg(5) and those best supported by recent versions of Jython.

Given that Swing was not a viable option considering the practical circumstances, the project team selected the multi-platform wxPython GUI framework after performing a proof of concept.

As the requirements of the Update Tool GUI expand and as a full coverage Java API for pkg(5) emerges, we will evaluate whether it makes sense for the GUI components to be reimplemented in Java.

Why isn't the Update Tool browser-based?

Since most server side products and applications already deliver their own browser based administrative applications, we encourage those adopters to consider using either the Java or Python pkg(5) API to integrate the update and add-on experience into their existing administrative consoles. The GlassFish v3 team has already taken this approach with their Administrative Console.

We expect to continue developing the Update Tool GUI and its companion Software Update GUI as thick clients for the foreseeable future.

pkg(5) Language Bindings

Is there a Java API for pkg(5)?

Yes. See the JavaDocs.

The Java API in its current form is a top to bottom Java implementation of a part of the pkg(5) client API. The limitations of this API are documented in the JavaDocs referenced above.

Is Jython used to implement the Java API?

No, not yet. Tom Mueller has run some initial experiments by deploying the Python-based pkg(5) client code on top of the pre-release Jython 2.5 code. Later in CY09 we expect to seriously consider providing a more full coverage Java API for pkg(5) by developing a thin Java shim on top of the existing Python API and running the Python API in a Jython 2.5 environment.

An obvious advantage of using Jython is that we will not have to reimplement perfectly good Python code in Java. Virtually all of the pkg(5) client API will be available to Java applications as compared to the partial coverage available in the initial Java API.

Note that Jython will be a dependency that will incur a download size cost. The good news is that the extra download is cross-platform.

Operating System Support

Solaris Support

Does pkg(5) multi-platform support Solaris?

Yes. The Update Center 2 Toolkit project maintains the port of pkg(5) and the associated tools for Solaris 10 and a variety of other OS platforms. See the OS Platform Notes document for details. This document outlines special considerations related to the Update Tool GUI when using the toolkit on Solaris 9.

Is pkg(5) available in SVR4 package format?

No. For all supported OS platforms including Solaris 10, the Update Center 2 port of pkg(5) delivers a set of pkg(5) format packages containing the toolkit binaries. These packages are available for layered or unbundled distributions to embed in their install bundles and the associated package repositories.

How does pkg(5) on Solaris 10 differ from the implementation in OpenSolaris?

As with all ports of pkg(5) owned by the Update Center 2 project, the port for Solaris 10 focuses on supporting the use of "user images". Features associated with user images are supported in the ports of pkg(5). Features specific to OpenSolaris and to "full" and "partial" images are not supported by the toolkit. For example, the integration of Solaris alternate boot environments and ZFS does not apply to the toolkit's use of user images on Solaris and OpenSolaris.

Does the port of pkg(5) support Zones on Solaris 10?

Yes in the sense that the user images can be deployed to both global and non-global zones. With global zones, if you want your installed application to be made automatically visible to non-global zones, you will have to ensure that the filesystem on which the application is installed in the global zone is made available (likely in read only mode) to the non-global zones.

As long as the application is designed to support user-specified configuration and variable data locations, a user can leverage from a non-global zone, the binaries installed within a user image in the global zone.

The port of pkg(5) for Solaris 10 is not "zones aware" in the sense that per non-global zone copies of /etc and /var content are not applicable and not automatically represented in the non-global zones. The SVR4-oriented zones support on Solaris 10 knows nothing about layered application installations that happen to use pkg(5) as their packaging technology.

pkg(5) Porting Process

Doesn't the port of pkg(5) result in a fork?

No, not at all. The Update Center 2 project uses the time tested technique of keeping a copy of the pkg(5) source in its own source tree and using that copy as a buffer to insulate the toolkit project from the constant development that occurs in the main source repository.

Fixes and enhancements to the pkg(5) code, when they do occur in the toolkit project's source repository, are done only on a temporary basis until those changes are made in the mainline source repository.

How much does the port of pkg(5) lag from the mainline pkg(5) development?

The Update Center 2 project's goal is to sync with the pkg(5) main source branch at about the time a new named OpenSolaris release emerges. Currently, the OpenSolaris named releases are on a 6 month cadence.

For example, our January release of version 2.1 of the toolkit will contain at least all of the code from the OpenSolaris 2008.11 (November, 2008) release.