Don, Thanks for explaining the reasoning. Yes, I understand that it is a private patch and is part of a bundle. My question was, should we look into installing it on our system after I determine that all other patches in the bundle is already present? Or should we stay away from installing that patch? Please let me know, Thanks.
-GGR -- Rajiv G Gunja Blog: http://ossrocks.blogspot.com On Wed, Sep 8, 2010 at 05:16, Don O'Malley <don.omal...@oracle.com> wrote: > Hi Rajiv/All, > > There are a couple of points of note here... > > Essentially Oracle wanted a way of being easily able to determine when a > customer had applied the Patch Bundle for a Solaris Update. The Patch > Bundles are seen as having the closest relationship to upgrading to the > latest Solaris Update, without actually doing an upgrade. Upgrading systems > to the latest Solaris Release is the recommended support strategy, but we > realize that this may not always be possible, due to issues like needing to > re-certify apps on upgrade which is why we introduced the Patch Bundles. > The solution that we came up with (and there were many alternatives > discussed) to identify when a Patch Bundle has been successfully applied to > a system, was to add a "private" patch to the patch bundle to update > /etc/release to indicate that a particular Patch Bundle had been applied. > > It is worth pointing out here that my team does extensive testing of the > Patch Bundle, starting months before the bundle is due to be released (which > typically happens 2-4 weeks after GA of a Solaris Update). The "private" > patches that make the updates to /etc/release are not made public, purely > because there is no logical reason to do so; their purpose is to indicate > that a particular Patch Bundle has been applied and this is only true if a > customer actually downloads and installs the bundle itself. We can guarantee > that the patches in the Patch Bundle have undergone extensive testing and > there is also logic in the installcluster script that adds value not > available through automated patching tools. > > The advantage to Oracle of having this information is more from the > perspective of support. > Is a customer has an issue and supplies Oracle with an explorer log of the > system in question, then it is very useful for the engineer examining the > system to have a quick reference point in /etc/release that explains the > installation of a couple of hundred patches. > > I hope this explains why we have approached this the way that we have... > > Best, > -Don > > > > Rajiv Gunja wrote: > > Martin, > I just noticed this on Solaris Patch Update Aug 2010. > ----------- > > http://blogs.sun.com/patch/resource/Oracle_Solaris_Patch_Update_Aug_2010.pdf > *(PAGE 69)* > ----------- > Solaris Update Patch Bundles now update /etc/release to > make it easier to identify that a system has been patched > to the software level of a Solaris Update release. > ----------- > How will this effect us? Can we simulate this or is this addition/change > included as a part of kernel patch or part of their wrapper? > Do you know? Should also be a question for Don. Please advise. Thanks > > -GGR > > -- > Rajiv G Gunja > Blog: http://ossrocks.blogspot.com > > > -- > <http://www.oracle.com/> > *Don O'Malley* > Manager, Patch System Test > Revenue Product Engineering | Solaris | Hardware > East Point Business Park, Dublin 3, Ireland > Phone: +353 1 8199764 > Team Alias: rpe_patch_system_test...@oracle.com > <http://www.oracle.com/commitment> >
<<green-logo.gif>>
<<graphics1>>
