Could we approach this a different way by first getting a list of missing
patches relevant to a patchdiag slightly *newer* than the CPU, then filter that
list with the list of patches on the CPU?
e.g.,
pca missing > patches.missing.full
for patch in `cat cpu_patches.lst | cut -d- -f1`; do
patch_id=`echo $patch | cut -d- -f1`
grep ^$patch_id patches.missing.full && echo $patch >
cpu_patches_check.lst
done; pca -l $(chkmin $(cat cpu_patches_check.lst))
The chkmin is to avoid re-installing the same release of a patch if the
patchdiag.xref contains a newer release than the CPU.
I haven't tried any of the above to see if it produces a list as I'm dreading
trying to navigate Oracle support to see if there's a way to get the recent CPU
patch_order file without downloading the 2GB zip file.
Ateeq
-----Original Message-----
From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On
Behalf Of Martin Paul
Sent: 15 June 2011 10:07
To: PCA (Patch Check Advanced) Discussion
Subject: Re: [pca] Oracle removed support from patchdiag.xref for --minimal
option in pca?
Jeff wrote:
> It does reduce the number of patches to 100, but the problem still exists
> that pca doesn't verify the packages are installed that the patches applies
> to if a specific revision is requested. So in the case of the server I'm
> testing, it was built with the SUNWCrnet cluster, so it has minimal packages
> and the actual number that would be applied is around 10.
I see, you're right. It only makes sense if you stick to the "Entire
Distribution" cluster.
> I really think the best solution is to either convince Oracle to package a
> patchdiag.xref that cooresponds with the revisions in the CPU within the CPU
> bundle, or for me to grab patchdiag.xrefs around the release date until I
> find one that cooresponds with the bundle.
Agreed, it would be best if Oracle provided a matching patchdiag.xref with each
CPU. Chances for that are pretty low, I guess. Same for finding an xref file
from a certain date which matches the CPU exactly.
As Don already mentioned, the ultimate solution would be to create a new
patchdiag.xref from scratch with the data from the patches in the CPU. All the
required information should be in patchinfo (PATCHID, PATCH_ARCH,
PATCH_REQUIRES), the README (Synopsis, Date) and the SUNW*/pkginfo files
(VERSION). The R/S flags aren't in there, but they won't matter.
Anybody want to try it? :) I guess I could come up with a rough script, it's the
fine-tuning and testing which scares me off, as it will take a lot of time.
> All I have to say is keep up the good work Martin, you are
> keeping a lot of Solaris shops afloat.
Thanks for that!
Martin.
This email and any attachment to it are confidential. Unless you are the
intended recipient, you may not use, copy or disclose either the message or any
information contained in the message. If you are not the intended recipient,
you should delete this email and notify the sender immediately.
Any views or opinions expressed in this email are those of the sender only,
unless otherwise stated. All copyright in any Capita material in this email is
reserved.
All emails, incoming and outgoing, may be recorded by Capita and monitored for
legitimate business purposes.
Capita exclude all liability for any loss or damage arising or resulting from
the receipt, use or transmission of this email to the fullest extent permitted
by law.
