Bugzilla – Bug 1218575
zypp patch category selection fails with overlapping patches
Last modified: 2024-01-09 15:46:28 UTC
While trying to reproduce bug 1218573 I found the following behavior that I believe is buggy: In short, if an update of type security is followed by an update of type recommended, and the patches overlap in at least one packages, selecting the corresponding patch category is ineffective. Additionally, installing the earlier patch by name exposes the same behavior. In full: Th prepare, fully patch, just downgrade two stacked updates: $ zypper patch $ zypper in --oldpackage -- procps=3.3.15-150000.7.31.1 libprocps7=3.3.15-150000.7.31.1 -libprocps8 The following packages are visible: $ zypper search -t package -s --match-exact -- procps libprocps7 libprocps8 S | Name | Type | Version | Arch | Repository ---+------------+---------+----------------------+--------+------------------------------------------------------------- v | libprocps7 | package | 3.3.15-150000.7.34.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | libprocps7 | package | 3.3.15-150000.7.31.1 | x86_64 | Main Repository | libprocps8 | package | 3.3.17-150000.7.37.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 v | procps | package | 3.3.17-150000.7.37.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 v | procps | package | 3.3.15-150000.7.34.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15 i+ | procps | package | 3.3.15-150000.7.31.1 | x86_64 | Main Repository Two updates are shown: one security update, and one recommended one. Both needed: $ zypper lp Repository | Name | Category | Severity | Interactive | Status | Since | Summary -------------------------------------------------------------+-----------------------------+-------------+----------+-------------+--------+------------+------------------------------ Update repository with updates from SUSE Linux Enterprise 15 | openSUSE-SLE-15.5-2023-3472 | security | low | --- | needed | 2024-01-05 | Security update for procps Update repository with updates from SUSE Linux Enterprise 15 | openSUSE-SLE-15.5-2024-11 | recommended | moderate | --- | needed | 2024-01-05 | Recommended update for procps Found 2 applicable patches: 2 patches needed (1 security patch) The actual issue: The following command pull in 3.3.17-150000.7.37.1 instead of 3.3.15-150000.7.34.1, and effectively install both patches: $ zypper in -t patch openSUSE-SLE-15.5-2023-3472 The following 2 packages are going to be upgraded: libprocps7 procps The following NEW package is going to be installed: libprocps8 The following NEW patch is going to be installed: openSUSE-SLE-15.5-2023-3472 2 packages to upgrade, 1 new. Overall download size: 388.3 KiB. Already cached: 0 B. After the operation, additional 103.6 KiB will be used. Continue? [y/n/v/...? shows all options] (y): Same for selection of security patches only: $ zypper patch -g security Loading repository data... Reading installed packages... Patch 'openSUSE-SLE-15.5-2024-11-1' is not in the specified category. Resolving package dependencies... The following 2 packages are going to be upgraded: libprocps7 procps The following NEW package is going to be installed: libprocps8 The following NEW patch is going to be installed: openSUSE-SLE-15.5-2023-3472 2 packages to upgrade, 1 new. Overall download size: 388.3 KiB. Already cached: 0 B. After the operation, additional 103.6 KiB will be used. Continue? [y/n/v/...? shows all options] (y): Executing wither of this will install openSUSE-SLE-15.5-2023-3472 (security) and openSUSE-SLE-15.5-2024-11 (recommended), despite not selecting them.
Well, a "patch" is not some kind of object you install like a package. A patch describes a vulnerability and it's status computed by looking at the set of installed packages. Downgrading a package may turn an 'applied' patch into a 'needed' one. This is what you did by downgrading to 'procps=3.3.15-150000.7.31.1'. All patches with fixes not included in 3.3.15-150000.7.31.1 will became 'needed' again. Vice versa updating 'procps' to the latest version will on the fly resolve all these needed patches again because the latest version contains all fixes. Selecting a patch will trigger the update of an affected package. But when updating the package, zypper will always aim for the latest version. The zypper man page tries to explain this: Package Types ... patch A released patch conflicts with the affected/vulnerable versions of a collection of packages. As long as any of these affected/vulnerable versions are installed, the conflict triggers and the patch is classified as needed, or as unwanted if the patch is locked. Selecting the patch, the conflict is resolved by updating all installed and affected/vulnerable packages to a version providing the fix. When updating the packages zypper always aims for the latest available version. Resolved patches are classified as either applied or not needed, depending on whether they refer to actually installed packages. So installation, update or removal of packages may change the classification of patches referring to these packages. Since libyzpp-17.23.0 the /var/log/zypp/history remembers if a committed transaction changes a patchs classification. If history data are available, patch tables show a column telling since when the patch is in it’s current state.