Bug 1218575

Summary:	zypp patch category selection fails with overlapping patches
Product:	[openSUSE] openSUSE Distribution	Reporter:	Andreas Stieger <Andreas.Stieger>
Component:	libzypp	Assignee:	E-mail List <zypp-maintainers>
Status:	RESOLVED INVALID	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	Leap 15.5
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE Leap 15.5
See Also:	https://bugzilla.opensuse.org/show_bug.cgi?id=1218573
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Andreas Stieger 2024-01-05 19:46:36 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.

Comment 1 Michael Andres 2024-01-09 15:46:28 UTC

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.