Re: [pca] confirming the validiting of a home grown patch_order file
- populating the xref - Assume only one rev (the last used in dependencies) is present per patch - Removing any obsolete flag and "Obsoleted by:" text inside the synopsis. Correct? Yup, think so. I can also do it this way... I got all the info I need, I can even imagine to allow the user to choose which method is the best for him Yes, at the end having an option would probably be best. Like if you would apply the 10 Recommended patch cluster without downloading every single patch which is in it. You simply could generate xref from the list of patches it contains and then run pca against this xref... wouldn't that be a wonderful world ? The basic design of Sun's patching design using patchdiag.xref really isn't (or wasn't) all that bad. Besides just having one current master xref file, one can put it to good use which such custom xref files; Sun, with the access to all the patch metadata could've done wonderful things. Alone the fact that one can use a "frozen" copy of an xref file to put a certain patching milestone on any given machine even months later is a great thing, used by many. It's just sad that all this has an expiration date on it since Solaris 11 and IPS appeared. Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
Thomas, So, from that point, I think that I can forget to remove patches being obsoleted by other PATCH_IDS (like if 11 was obsoleted by 22, we don't cause trouble by including both inside patchdiag.xref, right ? as PCA only got trouble when two patches with the same revision are present). Maybe you could just add required patches recursively in a first step, and then go over the file again and only keep one line per patch-ID - the one with the highest revision number. I think that should be fine for PCA, as it's the same style as used by the official patchdiag.xref. On another side, couldn't we add an option to PCA to allow obsoleted patches to be used ? I'd prefer not to do that :) It's hardly foreseeable whether this could cause problems in some obscure situations. With that change, PCA would accept that the xref file in itself doesn't have to be consistent, and not even I know the code good enough to anticipate what's gonna happen .. I think there's another viable solution: One could assume the only thing that happens when patch 11-01 is obsoleted by 22-02 is that its "O" flag is set and the synopsis is prefixed with "Obsoleted by: 22-02 ". So it should cause no harm if you simply remove these two things in the generated xref file. It seems to be a right thing to do - at the time when a patch required 11-01 for the first time, this of course wasn't obsolete yet. Again one could also argue that the most correct thing to do would be to follow the requirements/obsoletion chain until reaching a non-obsolete patch and to include that one (plus all the redirections, for PCA to know), even if this pulls in new dependencies. But then especially people with hand-tuned patch lists won't like that. *sigh* :) Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
Martin, Thanks for your input! I can understand the fact that 123839-01 is superseeded by 126897-02, and so it got removed from the generated xref when 126897 has been added. Causing PCA to have trouble resolving deps, as the patch 125503 is only mentionning 123839. So, from that point, I think that I can forget to remove patches being obsoleted by other PATCH_IDS (like if 11 was obsoleted by 22, we don't cause trouble by including both inside patchdiag.xref, right ? as PCA only got trouble when two patches with the same revision are present). This will increase again a little bit the size of the patchdiag.xref, but will help PCA to find everything it needs. On another side, couldn't we add an option to PCA to allow obsoleted patches to be used ? I mean, a lot of patches from the 10 Recommended patch cluster are already obsoleted, so it's not a problem having obsoleted patches being used if they are the only alternative present inside the patchdiag.xref, itsn't it ? Giving the patchdiag.xref informations that _were_ present while this patch was active inside the xref would be possible, though it require again me storing more information inside the database, which already weight more than 8Gb of datas :) So it's the last option for me ;) Regards, Thomas On Tue, 31 Jan 2012 11:13:24 +0100 Martin Paul wrote: > Thomas Gouverneur wrote: > >>125369|05|Jan/01/70| | | | > >>125547|01|Jan/01/70| | | | > > > > For theses one I don't know again how to threat them... They are > > referenced as dependencies over some other patch but looks > > unresolvable (maybe they are internal release of theses > > patches). The first release that I can see downloaded for > > 125369 is the -10.. How to handle that while generating the > > patchdiag.xref ? > > I think that if a certain revision of patch is referenced in the > official xref file, this very revision has existed at some time. If > you don't have information about such a revision, I guess you can > only use the next more recent one that does exist. > > Looking at PCA's debug output with the sample patchdiag.xref, I see > two more problems: > >119574|02|Jun/15/05| | |O| > |10|sparc;|SUNWcsu:11.10.0,REV=2005.01.21.15.53;|Obsoleted by: > 140860-01 SunOS 5.10: su patch > > The patch is obsoleted by 140860-01, which is not included in the > xref. Basically, it would be enough to have 119574-02 to fulfill the > dependency, but PCA won't use obsoleted patches, but follow the > obsoletion chain until it finds a non-obsolete patch. So you could > include 140860-01 in the xref file, but a better solution might be to > include the information about 119574-02 from the time when it was not > obsoleted yet. The more obsoletions one follows, the more > dependencies will be pulled in. That's a rather basic question: Is it > better to install only the minimum required revisions or should one > try to get the most recent patches to fulfill dependencies? > > Then there's a problem with . It's required by 125503, but > it's not included. Now when looking at the official xref file, one > can see that it has been obsoleted by 126897-02, which *is* included > in your xref. So actually the dependencies are fulfilled, but PCA > can't know about that, because it only sees what's included in the > short xref. I guess one will have to include that information in the > generated xref as well. > > I appreciate your work, but I'm somehow starting to doubt that this > is really possible to generate a consistent xref file for any given > set of patches (in a reasonable amount of time) .. > > Martin. > -- Thomas Gouverneur _ _ | |___ _ __ (_)_ __ | _| / __| '_ \| \ \/ / | |___\__ \ |_) | |> < |_|___/ .__/|_/_/\_\ Network |_| SPRL TVA: BE683601811 T: +32 498 23 00 40 W: http://espix.net M:
Re: [pca] confirming the validiting of a home grown patch_order file
Thomas Gouverneur wrote: 125369|05|Jan/01/70| | | | 125547|01|Jan/01/70| | | | For theses one I don't know again how to threat them... They are referenced as dependencies over some other patch but looks unresolvable (maybe they are internal release of theses patches). The first release that I can see downloaded for 125369 is the -10.. How to handle that while generating the patchdiag.xref ? I think that if a certain revision of patch is referenced in the official xref file, this very revision has existed at some time. If you don't have information about such a revision, I guess you can only use the next more recent one that does exist. Looking at PCA's debug output with the sample patchdiag.xref, I see two more problems: 119574|02|Jun/15/05| | |O| |10|sparc;|SUNWcsu:11.10.0,REV=2005.01.21.15.53;|Obsoleted by: 140860-01 SunOS 5.10: su patch The patch is obsoleted by 140860-01, which is not included in the xref. Basically, it would be enough to have 119574-02 to fulfill the dependency, but PCA won't use obsoleted patches, but follow the obsoletion chain until it finds a non-obsolete patch. So you could include 140860-01 in the xref file, but a better solution might be to include the information about 119574-02 from the time when it was not obsoleted yet. The more obsoletions one follows, the more dependencies will be pulled in. That's a rather basic question: Is it better to install only the minimum required revisions or should one try to get the most recent patches to fulfill dependencies? Then there's a problem with 123839-01. It's required by 125503, but it's not included. Now when looking at the official xref file, one can see that it has been obsoleted by 126897-02, which *is* included in your xref. So actually the dependencies are fulfilled, but PCA can't know about that, because it only sees what's included in the short xref. I guess one will have to include that information in the generated xref as well. I appreciate your work, but I'm somehow starting to doubt that this is really possible to generate a consistent xref file for any given set of patches (in a reasonable amount of time) .. Martin.
