[pca] confirming the validiting of a home grown patch_order file

[Martin Paul]

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.