[pca] PCA not reporting on patches that may need to be re-installed

[Norman Lyon]

I see what you see in S9 and S10.  I don't care about S8, but the  
story is a tad more complex with more than just 2 architectures  
(sun4[dmu]).

BUT, what I'm seeing, at least in 9 and 10, is that (at least with the  
patches in the EIS bundles), if different architectures share a common  
package version and package name, the patches that apply to the  
package is updated for both architectures (I'm ignoring x86 here,  
since that has only 1 arch type, so I don't foresee an issue....).   
Therefore if I have a particular version identifier for a package, and  
the patch patches that package:version, it'll patch it, regardless of  
architecture.

So, my current question for you is, do you have any more info on the  
problems you had?

Quoting Martin Paul <martin at par.univie.ac.at>:

> Norman Lyon wrote:
>> Wait....  Can't we just drop the '.$ARCH' concern and look at the REV=
>> part of the VERSION?  From my initial checking, I'm seeing that the
>> multiple package names are showing up with different versions.......
>
> Seems as if we're getting to the very core of the problem. You are  
> right, in your example one could ignore ARCH, as the VERSION is  
> enough to differ between the packages; I had not noticed that yet.  
> It's not valid for all packages, though.
>
> I looked up the problem reports I got back in 2008/09 when I had  
> added recognition of partly installed patches to pca, and it was  
> exactly the packages which have the same VERSION for all *.ARCH  
> packages which caused problems. Unfortunately this mostly affected  
> kernel patches, so pca started trying to re-install those which made  
> me retract the code quickly.
>
> I've grep'ed for "VERSION" in Product/*.*/pkginfo now for Solaris 9  
> 9/05 and 10 10/08 now on my jumpstart server. Here's a list of  
> affected packages for Solaris 10 (the one for Solaris 9 is longer):
>
>   FJSVvplr.u/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25
>   FJSVvplr.us/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25
>   FJSVvplu.u/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25
>   FJSVvplu.us/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25
>   SUNWiopc.u/pkginfo:VERSION=11.10.0,REV=2006.07.11.11.28
>   SUNWiopc.v/pkginfo:VERSION=11.10.0,REV=2006.07.11.11.28
>   SUNWnxge.u/pkginfo:VERSION=11.10.0,REV=2007.07.08.17.44
>   SUNWnxge.v/pkginfo:VERSION=11.10.0,REV=2007.07.08.17.44
>
> There are no problems when a patch includes e.g. both SUNWnxge.u and  
> SUNWnxge.v, as then on both sun4u and sun4v the package will be  
> patched.
>
> The problem is e.g. 120011-14, which includes only SUNWiopc.v. So  
> installing the patch on sun4u, SUNWiopc will not be patched, and the  
> routine to find unpatched packages shows a false positive, as  
> SUNWiopc:11.10.0,REV=2006.07.11.11.28 is installed but not listed in  
> "showrev -p".
>
> It's too bad - at the end, it's only a handful of patches which will  
> break the detection routine for partly installed patches, but for  
> those there's no standard way to identify them from xref data. Some  
> kind of hard-coded whitelist would be necessary to ignore certain  
> patches and/or packages, but it will be nearly impossible to really  
> test this with a reasonable amount of time and effort.
>
> Still - if you decide to implement and use your local check script,  
> please let me know how it works out.
>
> Martin.
>
>