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
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 automaticly 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.