had some internal discussion on this so here's the copypasta:
Who decides which all patch come under a particular filter?
We go back and consult vendors. So for example if catalog filter is RHEL4 x86, Critical patches (or however rhn classifies them). We ask RHN site list of all patches that are for RHEL4, x86 platform and are termed as critical by Redhat. We get those patches in our catalogs. Time passes by and now vendor releases new patches and updates that list. Some of those patches accommodate fixes of some other already existing patch in list making them ‘obsolete’. To signify this change vendor updates metadata making that old patch obsolete. It may also mention a patch that obsoleted it.
Now, vendor may choose to retain that old obsolete patch along with the new ‘obsoleted by’ patch in repository.
If we now update our catalog, we get this new information. Our catalog will now have the new patch and existing patch but with the obsolete property marked to TRUE reflecting the change vendor did.
For Bladelogic this is still not ‘irrelevant’ as it is very much part of vendor’s list.
However if vendor chooses to mark it obsolete and remove it from the list. Our catalog update will notice the difference. Now catalog has a patch that is no longer part of vendor repository. It is this what makes that patch ‘irrelevant’ for a particular catalog definition. Instead of deleting it we choose to group it differently assuming that it is still being referred by some blpackage which is part of some deploy job. Our users can get rid of these patches at their own discretion by invoking ‘Remove irrelevant patches’ action.
My confusion is the mixed use of the term "irrelevant".
It apears to me that both the "Remove Irrelevant" feature and the "Irrelevant Patches" smart group both act on obsolete patches (as obsolete is defined in KA364929). I suspect those may also act on irrelevant patches, but I have not been able to test that scenario.
i can update the KA to make it more clear...
so w/ 'irrelevant' - if redhat comes out w/ newer patches, the old ones will become obsolete. an obsolete patch only becomes irrelevant when redhat removes that (now obsolete) patch from their list of patches that they send to us during the cuj. so if that happens, or you remove a filter from the catalog - those are the only times the SOFTWARE_PATCH_STATUS_FLAG should be set to 1 on a patch object in the catalog.
Thanks! That clears it up.