To conclude the series of the problems with
ARPSYSTEMCOMPONENT, we will extend the workaround to support setting
ARPSYSTEMCOMPONENT=1 to support Microsoft’s lifecycle policy on support N and N-1, where N would be a service pack, and N-1 would be the previous service pack or the RTM.
Since we’ve essentially already developed our own sequencing feature in order to keep patches in view at all times, we must also take care of removing those patches’ Add/Remove Program (ARP) registry entries when a patch is effectively superseded by a successive patch or service pack. We did that by defining unique properties for each patch and conditions that are also unique to each patch’s ARP component that successive patches can set to cause the transitive component condition to evaluate to true. It’s essentially the same idea as obsolescence — the method by which patches removed other patches from view before the more robust sequencing feature was added in Windows Installer 3.0. That works fine as long as the patch obsolescence chain of package codes is known at patch build time. To support N-1, however, patch package codes are not always known.
If a service pack is released, it would typically supersede all patches that target the previous service pack or the RTM. N-1 patches, however, are produced after that service pack is released to QA for testing and eventual RTM. The service pack couldn’t know about N-1 patches because they don’t yet exist. Under normal circumstances, that wouldn’t be a problem because the patch transforms would target a specific
ProductVersion, a service packs — minor updates — would change that
ProductVersion thus removing the patch from the view. Remember, though, that in order to control the addition and removal of our transitive components for ARP we changed the transforms so that they would always apply.
We need to adjust our conditions for the transitive components, then. Currently, the condition would be something like
NOT KB001.Replaced, where
KB001 is our unique identifying property defined by the patch. A superseding patch would define
KB001.Replaced, thus causing the transitive condition for the superseded patch to evaluate to false. Since we know that service packs are to change the
ProductVersion property, we can change the condition for small updates to
NOT KB001.Replaced OR ProductVersion = 1.0.0 or whatever version is suitable for the actual target of a small update. Minor updates should target the
ProductVersion that is the final version after the service pack is applied, like
NOT KB005.Replaced OR ProductVersion = 1.1.0. This also means that a service pack — which after several released service pack level would potentially define many replacement properties (ex:
KB001.Replaced) — would not need to list all patches it replaced because it will change the
ProductVersion and will cause the previous patches — even the N-1 patches — to be effectively superseded.