Re: [pca] Trouble installing two patches
James Adams wrote: Same problem, same patches. The patches aren't yet available for download yet. I had the same problem. As usual, waiting for 24 hours helped, and all patches are available for download now. Seems as if now and then new patches get stuck in the publication process somewhere. Martin.
[pca] Non-existing patch
Hi Don and all, In the READMEs of the new patches 124630-60 and 119534-29 a note has been added: NOTE: The list of 'patches required with this patch' (above) has been modified from the list specified at patch creation time. The reason for the modification is that one or more of the required patches was either never released or withdrawn after its release. The following substitutions (which are guaranteed to satisfy the original requirements) were therefore made: 124628-03 replaces 126677-02 This replacement is a good thing, but unfortunately it has only taken place in the README and not in the patchinfo files nor in patchdiag.xref - those still refer to 126677-02 (which, as the note says, has never been released). Now PCA has always taken care of that by internally replacing 126677-02 with 124628-03 when resolving dependencies, so there's no new problem. It would be nice, though, now that the problem has been noticed, to fix this issue in all places (patch README, patchinfo, patchdiag.xref) to make this consistent again. The same applies to the corresponding x86 patches, BTW (non-existant 126678 required by 124631 and 119535). And just for completeness, here is the list of all non-existant patches to be found as required patches in patchdiag.xref, and how they are taken care of in PCA: ($r eq 125077-02) ($r=120011-09); # 119757 ($r eq 125078-02) ($r=120012-10); # 119758 ($r eq 125486-01) ($r=120011-14); # 126206 ($r eq 125487-01) ($r=120012-14); # 126207 ($r eq 114431-03) ($r=117172-17); # 116473 Read like this: Patch 119757 requires 125077-02, which doesn't exist, so it should require 120011-09 instead. Martin.
Re: [pca] Non-existing patch
Isn't it because the 124628-02 is obsolete that it's not inside the patchdiag.xref ? -- Thomas Gouverneur _ _ | |___ _ __ (_)_ __ | _| / __| '_ \| \ \/ / | |___\__ \ |_) | | |_|___/ .__/|_/_/\_\ Network |_| SPRL TVA: BE683601811 T: +32 498 23 00 40 W: http://espix.net M: tho...@espix.net On Fri, 28 Oct 2011 12:11:28 +0200 Martin Paul mar...@par.univie.ac.at wrote: Hi Don and all, In the READMEs of the new patches 124630-60 and 119534-29 a note has been added: NOTE: The list of 'patches required with this patch' (above) has been modified from the list specified at patch creation time. The reason for the modification is that one or more of the required patches was either never released or withdrawn after its release. The following substitutions (which are guaranteed to satisfy the original requirements) were therefore made: 124628-03 replaces 126677-02 This replacement is a good thing, but unfortunately it has only taken place in the README and not in the patchinfo files nor in patchdiag.xref - those still refer to 126677-02 (which, as the note says, has never been released). Now PCA has always taken care of that by internally replacing 126677-02 with 124628-03 when resolving dependencies, so there's no new problem. It would be nice, though, now that the problem has been noticed, to fix this issue in all places (patch README, patchinfo, patchdiag.xref) to make this consistent again. The same applies to the corresponding x86 patches, BTW (non-existant 126678 required by 124631 and 119535). And just for completeness, here is the list of all non-existant patches to be found as required patches in patchdiag.xref, and how they are taken care of in PCA: ($r eq 125077-02) ($r=120011-09); # 119757 ($r eq 125078-02) ($r=120012-10); # 119758 ($r eq 125486-01) ($r=120011-14); # 126206 ($r eq 125487-01) ($r=120012-14); # 126207 ($r eq 114431-03) ($r=117172-17); # 116473 Read like this: Patch 119757 requires 125077-02, which doesn't exist, so it should require 120011-09 instead. Martin.
Re: [pca] Non-existing patch
Thomas Gouverneur wrote: Isn't it because the 124628-02 is obsolete that it's not inside the patchdiag.xref ? The problematic patch is 126677-02 - it's listed as required for 119534-29 and 124630-60 in patchdiag.xref, but there is no information about any revision of 126677 itself. Martin.
Re: [pca] Non-existing patch
I'm seeing 126677-02 as obsoleted by 124628-03, which is inside patchdiag.xref... but indeed then there is a multi-level dependency that's not inside patchdiag.xref... :/ Maybe it's the 119534-29 which should directly link to 124628% instead of 126677... -- Thomas Gouverneur _ _ | |___ _ __ (_)_ __ | _| / __| '_ \| \ \/ / | |___\__ \ |_) | | |_|___/ .__/|_/_/\_\ Network |_| SPRL TVA: BE683601811 T: +32 498 23 00 40 W: http://espix.net M: tho...@espix.net On Fri, 28 Oct 2011 12:33:04 +0200 Martin Paul mar...@par.univie.ac.at wrote: Thomas Gouverneur wrote: Isn't it because the 124628-02 is obsolete that it's not inside the patchdiag.xref ? The problematic patch is 126677-02 - it's listed as required for 119534-29 and 124630-60 in patchdiag.xref, but there is no information about any revision of 126677 itself. Martin.
Re: [pca] Non-existing patch
Hi Martin, The addition of this note is the result of a looong email thread internally. We were discussing whether we could internally update the backing database which generates patchdiag or not. After investigation it turns out that the database could not handle an update to the actual 'requires' field, as there is an integrity check in place to ensure that the 'requires' field is consistent with the info in the pkginfo SUNW_REQUIRES filed (which patchadd uses to resolve patch dependencies). Essentially, this check prevents us updating the database's patch requirements. For this reason the README update was seen as the best possible alternative... I know it may sound a bit OTT that we cannot override these things, but when you need an extremely scalable solution (as we clearly do with over 30,000 patches available), then each error opportunity you introduce by allowing such audits to be overridden has a massive multiplier effect when you consider the number of individual patches that could have an issue as a result. Bottom line is that the potential cost far outweighs the potential gain. Thanks for sending on the list of additional patches with similar defects; I'll ensure they get similar README updates to indicate the replacement requirements. Hope this makes sense! Best, -Don On 28/10/11 11:11, Martin Paul wrote: Hi Don and all, In the READMEs of the new patches 124630-60 and 119534-29 a note has been added: NOTE: The list of 'patches required with this patch' (above) has been modified from the list specified at patch creation time. The reason for the modification is that one or more of the required patches was either never released or withdrawn after its release. The following substitutions (which are guaranteed to satisfy the original requirements) were therefore made: 124628-03 replaces 126677-02 This replacement is a good thing, but unfortunately it has only taken place in the README and not in the "patchinfo" files nor in patchdiag.xref - those still refer to 126677-02 (which, as the note says, has never been released). Now PCA has always taken care of that by internally replacing 126677-02 with 124628-03 when resolving dependencies, so there's no new problem. It would be nice, though, now that the problem has been noticed, to fix this issue in all places (patch README, patchinfo, patchdiag.xref) to make this consistent again. The same applies to the corresponding x86 patches, BTW (non-existant 126678 required by 124631 and 119535). And just for completeness, here is the list of all non-existant patches to be found as required patches in patchdiag.xref, and how they are taken care of in PCA: ($r eq "125077-02") ($r="120011-09"); # 119757 ($r eq "125078-02") ($r="120012-10"); # 119758 ($r eq "125486-01") ($r="120011-14"); # 126206 ($r eq "125487-01") ($r="120012-14"); # 126207 ($r eq "114431-03") ($r="117172-17"); # 116473 Read like this: Patch 119757 requires 125077-02, which doesn't exist, so it should require 120011-09 instead. Martin. -- 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
Re: [pca] Non-existing patch
Thomas Gouverneur wrote: Something that could be integrated into PCA, related to my other post on the mailling, is the new way of getting patches metadata (with XML API). This way, when you have a broken dep' like this, you could check the proper metadata of the missing patch directly @ Oracle and resolve the dependency automatically, without having to link theses patches inside PCA's code.. What do you think ? Even if one would cache most (of the old) patch metadata, getting the rest on every run of PCA would be pretty slow, I guess. Then there are many PCA users who run it on machines with no (or only internal) network connection. I think having one file with all the metadata makes much more sense than spreading it over thousands of single XML URLs (especially as it allows tools like PCA to go back in time by using old xref files). It's sad that Oracle never found it important enough to add extra fields we are missing to the xref file (like checksums, etc.), though. *IF* the XML interface proves to be fast and stable, and *IF* Oracle would allow outsiders to offer the contained information (which they don't now, AFAIK), one could think about a service which would get the xref file plus all the extra information from the XML links, combine it into an extended xref file with some new columns, and offer that file, reliable and daily. Like that, the information harvesting at least would have to be done only once, and not by every PCA user. Martin.
Re: [pca] Non-existing patch
2011/10/28 Martin Paul mar...@par.univie.ac.at: Thomas Gouverneur wrote: Something that could be integrated into PCA, related to my other post on the mailling, is the new way of getting patches metadata (with XML API). This way, when you have a broken dep' like this, you could check the proper metadata of the missing patch directly @ Oracle and resolve the dependency automatically, without having to link theses patches inside PCA's code.. What do you think ? My vote goes to the Martin's new idea! Even if one would cache most (of the old) patch metadata, getting the rest on every run of PCA would be pretty slow, I guess. Then there are many PCA users who run it on machines with no (or only internal) network connection. I think having one file with all the metadata makes much more sense than spreading it over thousands of single XML URLs (especially as it allows tools like PCA to go back in time by using old xref files). It's sad that Oracle never found it important enough to add extra fields we are missing to the xref file (like checksums, etc.), though. *IF* the XML interface proves to be fast and stable, and *IF* Oracle would allow outsiders to offer the contained information (which they don't now, AFAIK), one could think about a service which would get the xref file plus all the extra information from the XML links, combine it into an extended xref file with some new columns, and offer that file, reliable and daily. Like that, the information harvesting at least would have to be done only once, and not by every PCA user. Martin. Martin, you're a genius! Toc toc! Excuse me, Mr.Oracle, what do you think? Bye Michele -- Michele Vecchiato e-mail mailto:michele.vecchiato::at::gmail.com Blog http://michelevecchiato.wordpress.com LinkedIn profile http://www.linkedin.com/in/michelevecchiato
