4 Replies Latest reply on Apr 24, 2014 7:04 AM by Jeff Orndorff

    obsolete vs irrelevant patches

      I am confused about the definition of obsolete and irrelevant patches.


      I see the knowledgebase article

      (https://kb.bmc.com/infocenter/index?page=content&id=KA364929&actp=search&viewlocale=en_US&searchid=1397503510939) provides a definition.  However I have existing RHEL patch catalogs in which the filter has never been changed.  When I right click the patch catalog, and then select "Remove irrelvant patches", many rpm packages are purged from the catalog.  These items fit the definition of obsolete patches.  They are patches which have been replace by newer patches.

      I also notice that there is an "out of the box" smart group named "Irrelevant Patches", which includes patches that are included under the current filter, but which have been replaced by newer patches.  This also fits the definition of obsolete patches from KA364929.


      Can anyone provide more information on these definitions?

      Does the update patch catalog process flag obsolete patches with SOFTWARE_PATCH_STATUS_FLAGS* set to 1?


      Does the "right click, remove Irrelevant Patches" selection on the patch catalog remove both obsolete and irrelevant?

        • 1. Re: obsolete vs irrelevant patches
          Bill Robinson

          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.

          • 2. Re: obsolete vs irrelevant patches

            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.

            • 3. Re: obsolete vs irrelevant patches
              Bill Robinson

              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.

              • 4. Re: obsolete vs irrelevant patches

                Thanks!  That clears it up.