Re: [pca] confirming the validiting of a home grown patch_order file
Don O'Malley wrote: Basically, as soon as you start to use patches in the form of xx-yy with PCA it will (and has to) assume that you take care of the dependencies and the ordering yourself. If you have a self-maintained list of patches, it's probably easiest to to try to install them on a test machine to get the correct ordering. Dumping all the patches in a single directory and using 'patchadd -M' may help... A recent idea for a service that Oracle could provide was to allow a customer to submit a list of patch-IDs and revisions, and to get a copy of patchdiag.xref which includes exactly these patches (plus required patches) in return. This patchdiag.xref file could then be fed into PCA via its xrefdir option, and it would allow the admin to verify any system against (and patch up to) this very patchset. This would not only be useful for such home-grown patch lists (which Oracle doesn't like anyway), but also for patching prerequisites enforced by some applications. E.g. Sun Studio, which always had a list of certain required and/or recommended patches to be installed to make it work flawlessly. It's a common FAQ as to how to verify such a list. If a patchdiag.xref with these patches would be provided, again checking and patching would be a breeze. Any spare time, Don? :) Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
Martin, I've tried to make a PoC for all this... To generate a custom patchdiag.xref based on a patch list: - Register on wesunsolve.net - Login - Create a custom patch list (http://wesunsolve.net/add_clist) - Add some patch into it.. * visit a patch page, select the list in the drop down menu on the upper side of the page and click add... - get back to your panel (http://wesunsolve.net/panel) - Click on Generate patchdiag.xref - This should give you a patchdiag.xref customized with only the patch that you requested + recursives dependancies... I plan to allow the generation of theses patchdiag also for patch clusters and also ease the process (outside of user lists also, just copy/paste a list of patch and get the patchdiag associated...) Can someone provide me feedback about theses custom patchdiag.xref ? I didn't really tested the data that are exported there.. but I think they should be relevant... Kind Regards, -- Thomas Gouverneur T: +32 498 23 00 40 W: http://espix.net M: tho...@espix.net On Fri, 27 Jan 2012 09:40:15 +0100 Martin Paul mar...@par.univie.ac.at wrote: Don O'Malley wrote: Basically, as soon as you start to use patches in the form of xx-yy with PCA it will (and has to) assume that you take care of the dependencies and the ordering yourself. If you have a self-maintained list of patches, it's probably easiest to to try to install them on a test machine to get the correct ordering. Dumping all the patches in a single directory and using 'patchadd -M' may help... A recent idea for a service that Oracle could provide was to allow a customer to submit a list of patch-IDs and revisions, and to get a copy of patchdiag.xref which includes exactly these patches (plus required patches) in return. This patchdiag.xref file could then be fed into PCA via its xrefdir option, and it would allow the admin to verify any system against (and patch up to) this very patchset. This would not only be useful for such home-grown patch lists (which Oracle doesn't like anyway), but also for patching prerequisites enforced by some applications. E.g. Sun Studio, which always had a list of certain required and/or recommended patches to be installed to make it work flawlessly. It's a common FAQ as to how to verify such a list. If a patchdiag.xref with these patches would be provided, again checking and patching would be a breeze. Any spare time, Don? :) Martin.
Re: [pca] confirming the validiting of a home grown patch_order file
Thomas Gouverneur wrote: I've tried to make a PoC for all this... You're quick :) Can you please change the header in the generated xref file to match the one from the original, ie: ## PATCHDIAG TOOL CROSS-REFERENCE FILE AS OF Jan/26/12 ## PCA is quite picky with the syntax of the first line and won't accept the file if it doesn't match. You can put the FOR BUNDLE xxx part into another comment line (they are ignored by PCA). Even in a simple example with just one patch on the list, which pulls in a kernel patch, I once again realized how complicated all those patch dependencies have become, and how difficult it is to prove correctness. One thing I noticed is that the xref file contains lines like 119254|14|Jan/01/70| | | | . It seems as if the xref creator doesn't check whether a patch has already been included with a higher revision, and then adds these half-empty lines. When different patches require different revisions of some other patch, only one line with the newest required revision should be included. I also saw a bad patch (B) included in the xref file (120272-12). I guess the script should look for the patch which obsoleted it and include that one instead. The format of the lines themselves seems to be OK. Are you generating them from your patch database or are they taken from your archive of patchdiag.xref files? Guess that more people have to try that with real-world examples to see whether the output makes sense and delivers a patch set which can indeed be applied. Trying to analyze that with a handful of theoretical samples seems just too complicated and cumbersome. Martin.
