What are Solaris 10 Updates made of: Patches and scripts and packages, too.

There seems to be some confusion about what a Solaris Update release is, both in and outside of the company, so I'd like to take an opportunity to explain how we are currently generating Solaris update releases.

First of all, a reminder, I am the technical lead for just the ON Consolidation for Solaris 10 Update 1. All of Solaris, aka the WOS, is made up of various consolidations. ON, the Operating System and Networking Consolidation, is just one of them. I can speak about how we handle things in ON land, but cannot promise that the same things apply across all consolidations. Most of ON is now available in OpenSolaris, to give you an idea of what code base I'm talking about. Mike Kupfer gives a good background on the ON consolidation.

The other caveat: there are exceptions. I will lay out first the basic structures of an update. Later entries will talk more about the exceptions and more fancy things, like features.

My mantra throughout this release has been "the patch gate is the update gate is the patch gate is the update gate...". I even included that in the gate's README file.

Put another way, update releases are made up almost entirely of patches, most of which are released early on SunSolve to provide binary relief to customers.

The most basic things that an update release contains are bug fixes, which I'll cover in this entry. These bugs may have been found internally or may have been reported by an external customer who escalated the issue. When a bug is fixed, it is first integrated in the release under development, in this case Nevada, where it undergoes significant testing and gains exposure on our internal servers and desktops. We call that "soaking".

After soak has completed, the fix comes back to the sustaining gate, on10-patch, where we do milestone builds every two weeks. At the end of a build, we will cut at least one patch for each integration we took for each applicable architecture and deliver those for further testing. The final patches will typically end up on SunSolve and are also used to create what is known as a Freshbit image of Solaris. Essentially, we start with an GA version of Solaris 10 and install patches on top of that image, to create an update build. That is, if the fix was not included in a patch, it will not be part of the update release.

Patches are cumulative so if patch A-01 contains a fix for bug X, patch A-02 will also contain a fix for bug X + some other bug fixes. Therefor, update builds are also cumulative. If something was fixed in a patch applied to the freshbit image of s10u1_01 it will still be fixed in s10u1_02 and so on.

In theory, you can take a base Solaris 10 03/05 system and patch up to an update release. In fact, you may remember when Sun used to release MUs (Maintenance Updates) which would basicly install the base OS then spend a couple of hours automatically patching it. Those where the bad ol' days - now we do the patching for you, and you can just upgrade or do a fresh install, getting essentially Solaris 10 03/05 and all relevant patches for your hardware.

Of course, there are exceptions, but most of those are not relevant for existing install base for Solaris 10 03/05.

I hope this helps to explain things a bit. I will have more entries, soon, to explain how features and new packages are handled and tested. let me know if any of this does not make sense, or if you have any specific questions on the interaction of patches and updates.