Bug 1203088

Summary:	Patch should not conflict with packages from different vendor (on example of patch:openSUSE-SLE-15.4-2022-2969)
Product:	[openSUSE] openSUSE Distribution	Reporter:	Andrei Borzenkov <arvidjaar>
Component:	libzypp	Assignee:	E-mail List <zypp-maintainers>
Status:	RESOLVED FEATURE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	bzeller, guenter.halt, mls
Version:	Leap 15.4
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	zypper patch with conflict with Packman part 1 zypper patch with conflict with Packman part 2 zypper patch nothing to do part 1 zypper patch nothing to do part 2

Description Andrei Borzenkov 2022-09-03 14:03:15 UTC

Created attachment 861285 [details]
zypper patch with conflict with Packman part 1

Consider

bor@10:~> zypper lp
Loading repository data...
Reading installed packages...

Repository                                                   | Name                        | Category | Severity | Interactive | Status   | Summary
-------------------------------------------------------------+-----------------------------+----------+----------+-------------+----------+-------------------------------------
Update repository with updates from SUSE Linux Enterprise 15 | openSUSE-SLE-15.4-2022-2969 | optional | moderate | ---         | optional | Optional update for SUSE Package Hub

Found 1 applicable patch:
1 patch optional             (use '--with-optional' to include optional patches)
0 patches needed (0 security patches)

bor@10:~> sudo zypper patch --with-optional
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: the to be installed patch:openSUSE-SLE-15.4-2022-2969-1.noarch conflicts with 'libswscale5_9.x86_64 < 4.4-150400.3.2.1' provided by the installed libswscale5_9-4.4-pm154.2.6.x86_64
 Solution 1: Following actions will be done:
  install libswscale5_9-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/>
    replacing libswscale5_9-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de
  install libswresample3_9-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/>
    replacing libswresample3_9-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de
  install libpostproc55_9-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/>
    replacing libpostproc55_9-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de
  install libavutil56_70-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/>
    replacing libavutil56_70-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de
  install libavresample4_0-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/>
    replacing libavresample4_0-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de
  install libavformat58_76-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/>
    replacing libavformat58_76-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de
  install libavfilter7_110-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/>
    replacing libavfilter7_110-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de
  install libavcodec58_134-4.4-150400.3.2.1.x86_64 from vendor SUSE LLC <https://www.suse.com/>
    replacing libavcodec58_134-4.4-pm154.2.6.x86_64 from vendor http://packman.links2linux.de
 Solution 2: do not install patch:openSUSE-SLE-15.4-2022-2969-1.noarch

Choose from above solutions by number or cancel [1/2/c/d/?] (c): 

But that is wrong. These packages are from another vendor/repository so patch for (open)SUSE packages is not applicable to them at all.

Moreover, it I update the outdated package(s) from SUSE, the patch is no more considered applicable, even though the same "downrev" ffmpeg libraries are still present. This is certainly inconsistent.

bor@10:~> sudo zypper up
Loading repository data...
Reading installed packages...

The following 14 package updates will NOT be installed:
  libavcodec57 libavcodec58_134 libavfilter7_110 libavformat57 libavformat58_76
  libavresample4_0 libavutil55 libavutil56_70 libfdk-aac2 libpostproc55_9
  libswresample2 libswresample3_9 libswscale4 libswscale5_9

The following package is going to be upgraded:
  gucharmap

1 package to upgrade.
Overall download size: 123.3 KiB. Already cached: 0 B. No additional space will
be used or freed after the operation.
Continue? [y/n/v/...? shows all options] (y): 
Retrieving package gucharmap-13.0.0-150400.4.2.3.x86_64
                                           (1/1), 123.3 KiB (278.1 KiB unpacked)
Retrieving: gucharmap-13.0.0-150400.4.2.3.x86_64.rpm .....................[done]

Checking for file conflicts: .............................................[done]
(1/1) Installing: gucharmap-13.0.0-150400.4.2.3.x86_64 ...................[done]
 
bor@10:~> zypper lp
Loading repository data...
Reading installed packages...
No updates found.

bor@10:~> 

I attach two debug solver cases, one for "zypper patch" with outdated package gucharmap and one with "zypper patch" where the only "downrev" packages are from  Packman.

Comment 1 Andrei Borzenkov 2022-09-03 14:03:42 UTC

Created attachment 861286 [details]
zypper patch with conflict with Packman part 2

Comment 2 Andrei Borzenkov 2022-09-03 14:04:26 UTC

Created attachment 861287 [details]
zypper patch nothing to do part 1

Comment 3 Andrei Borzenkov 2022-09-03 14:04:52 UTC

Created attachment 861288 [details]
zypper patch nothing to do part 2

Comment 4 Andreas Stieger 2022-09-07 09:00:15 UTC

*** Bug 1203150 has been marked as a duplicate of this bug. ***

Comment 5 Benjamin Zeller 2022-09-07 10:23:18 UTC

I'm not sure zypper patch does have extra code to check for 3rd party repositories / vendors. Michael Andres knows that code path better than me, he'll be back next week.

From what I can see in the output you want to install a patch that requires packages with a certain version number, packman does not provide those so in order to install the patch the packages from the official repository have to be installed. Since this is a vendor change zypper will ask if it should be done... 

Adding mls to double check if the solver should handle that differently.

Comment 6 Michael Schröder 2022-09-07 13:13:53 UTC

Works like designed, i.e. as requested by the maintenance team.

A patch can only be completely ignored, it cannot be ignored in parts. That is, if there is one package that needs to be updated for the patch, the patch is deemed applicable. The patch will then be enforced on all the packages regardless of the vendor.

In your case the patch updates the SUSE package "gucharmap", so it is applicable. It will also enforce the update of all the non-SUSE packages regardless of the vendor.

I know that this is not super useful, but that's what we had to implement.

Comment 7 Michael Schröder 2022-09-07 13:16:27 UTC

I think the idea was that you can manually select a patch that was classified as not applicable because of the vendor, and so enforce the updates/vendor changes.

Comment 8 Benjamin Zeller 2022-09-07 16:19:54 UTC

I'd guess it was implemented in this way so that no patches are missed. 
Like in this case it would've been not visible that there is a patch for "gucharmap" if the solver would simply ignore patches that would enforce a vendor change.
 
Given that this is the expected behavior I'm closing the bug as "FEATURE".