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 111111 was obsoleted by 222222, 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 <mar...@par.univie.ac.at> 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: <tho...@espix.net>
