Tuesday Nov 29, 2011

Package Version Numbers, why are they so important

One of the design goals of IPS has been to allow people to easily move forward to a supported "Surface" of component. That is to say, when you 

# pkg update

your system, you get the latest set of components which all work together, based on the packages you already have installed. During development, this has meant simply you update to the latest "build" of the components. (During development, we build everything and publish everything every two weeks).

Now we've released Solaris 11 using the IPS technologies, things are a bit more complicated. We need to be able to reflect all the types of Solaris release we are doing. For example Solaris Development builds, Solaris Update builds and "Support Repository Updates" (the replacement for patches) in the version scheme. So simply saying "151" as the build number isn't sufficient to articulate what you are running, or indeed what is available to update to

In my previous blog post I talked about creating your own package, and gave an example FMRI of


But it's probably more instructive to look at the FMRI of a Solaris package. The package "core-os" contains all the common utilities and daemons you need to use Solaris.

 $ pkg info core-os
          Name: system/core-os
       Summary: Core Solaris
   Description: Operating system core utilities, daemons, and configuration
      Category: System/Core
         State: Installed
     Publisher: solaris
       Version: 0.5.11
 Build Release: 5.11
Packaging Date: Wed Oct 19 07:04:57 2011
          Size: 25.14 MB
          FMRI: pkg://solaris/system/core-os@0.5.11,5.11-

The FMRI is what we will concentrate on here. In this package "solaris" is the publisher. You can use the pkg publisher command to see where the solaris publisher gets it's bits from

$ pkg publisher
PUBLISHER                             TYPE     STATUS   URI
solaris                               origin   online   http://pkg.oracle.com/solaris/release/

So we can see we get solaris packages from pkg.oracle.com.  The package name is system/core-os. These can be arbitrary length, just to allow you to group similar packages together. Now on the the interesting? bit, the versions, everything after the @ is part of the version. IPS will only upgrade to a "higher" version.


core-os = Package Name

0.5.11 = Component - in this case we're saying it's a SunOS 5.11 package

, = separator

5.11 = Built on version - to indicate what OS version you built the package on

- = another separator = Branch Version

: = yet another separator

20111019T070457Z = Time stamp when the package was published

So from that we can see the Branch Version seems rather complex. It is necessarily so, to allow us to describe the hierarchy of releases we do In this example we see the following

0.175: is known as the trunkid, and is incremented each build of a new release of Solaris. During Solaris 11 this should not change 

0: is the Update release for Solaris. 0 for FCS, 1 for update 1 etc

0: is the SRU for Solaris. 0 for FCS, 1 for SRU 1 etc

0: is reserved for future use

2: Build number of the SRU

1: Nightly ID - only important for Solaris developers

Take a hypothetical example


This would be build 4 of SRU 5 of Update 1 of Solaris 11

This is actually documented in a MOS article 1378134.1 Which you can read if you have a support contract.

Tuesday Oct 04, 2011

How to create your own IPS packages

It's been ages since I blogged, so apologies for that. I'm at Oracle Openworld 2011 this week, and I was helping out on the Solaris booths in the DemoGrounds. One of the people I talked to asked a question, which I've heard internally at Oracle a few times recently. That is "How can I package up my own app as an IPS package?" I've answered it a few times, and so suddenly it struck me as a good subject for a blog.

 Most of this information is available either in the documentation,  or other blogs, but this is also for me to reference back to (rather than my notes)

With IPS, packages are published to a repository (or repo). This can either be a special pkg web server or simply a directory. For simplicity I've used the latter

$ export PKGREPO=/path/to/repo

$ pkgrepo create $PKGREPO 

This populates the $PKGREPO with the required repository structure, you only need to do this once.

Packages are described by manifests. You need one per package. If you have existing System V packages, you can allow the tools to generate it all for you, but simply passing the SystemV package file in the a tool called pkgsend

$ pkgsend generate sysvpkg > sysvpkg.mf

However, often my own tools are just added manually by hand or archived together with tar. So if I want to turn those in to an IPS package, I need to create my own manifest. Again fortunately pkgsend can help, but you'll need to add some details.

 So let's assume I've put all my tools in /opt/mytools

$ export ROOT=/opt/mytools
$ pkgsend generate $ROOT > mytools.mf

This manifest needs a line adding to it to describe the package

set name=pkg.fmri \

This states the publisher (tools), package name (mytools) and the version (1.3,0.5.11-0.0.0)

So once you have the working manifest - and there's a lot more detail we can add to these,  they can be published. (to the $PKGREPO directory we created earlier)

$ pkgsend publish -s $PKGREPO -d $ROOT mypkg.mf

Note for each successfully published you get a "Published" message, but silent failure (exit code is 1 though so it can be detected in a script)

You can then add the repo you've just populated to your test machine. You'll need to do this a as a privileged user, such as root

# pkg set-publisher -O $PKGREPO tools

and add a package

# pkg install mytools  Packages to install:  1
Create boot environment: No

DOWNLOAD                                  PKGS       FILES    XFER (MB)
Completed                                  1/1     716/716      2.4/2.4

PHASE                                        ACTIONS
Install Phase                                746/746

PHASE                                          ITEMS
Package State Update Phase                       1/1
Image State Update Phase                         2/2

PHASE                                          ITEMS
Reading Existing Index                           8/8
Indexing Packages                                1/1

So this is now installed on my system. There are so many interesting things you can add to the manifest, that if you're interested, I'll try to blog about in the future. However one thing I've glossed over here is the package version. It's surprisingly important that you understand what you set that to, so I'll make that the subject of a future blog.


Chris W Beal-Oracle


« July 2016