Thomas,
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).
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 111111-01 is obsoleted by 222222-02 is that its "O" flag is set and the synopsis is prefixed with "Obsoleted by: 222222-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 111111-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.
