How to handle vendor change when replacing a package
Hello List, We are trying to replace a package in our product that provides the same functionality. We have made changes to our package as documented at - https://en.opensuse.org/openSUSE:Upgrade_dependencies_explanation - but when "zypper patch" command is run, we are receiving a vendor conflict. If we run "zypper patch --allow-vendor-change" then the package dependencies are handled correctly. Both the vendor names are set to be equivalent. Hence my question is, how can we handle the vendor conflict when replacing a package? Any insights here would be greatly appreciated. Regards, Srinidhi.
On Mon, Dec 05, 2022 at 10:50:24AM +0000, Srinidhi B wrote:
Hello List,
We are trying to replace a package in our product that provides the same functionality. We have made changes to our package as documented at - https://en.opensuse.org/openSUSE:Upgrade_dependencies_explanation - but when "zypper patch" command is run, we are receiving a vendor conflict. If we run "zypper patch --allow-vendor-change" then the package dependencies are handled correctly.
Both the vendor names are set to be equivalent.
Changing repositories will trigger this logic. An RPM can have an 'vendor' associated with it, but if that RPM is coming from a different repo than initially installed from, then it's deemed a vendor change. Mind you, this is based on my own experience, as opposed to having a direct understanding of how zypper is designed to work.
Hence my question is, how can we handle the vendor conflict when replacing a package? Any insights here would be greatly appreciated.
Doesn't '--allow-vendor-change' allow you to do this? Perhaps I'm misunderstanding your question.
Regards, Srinidhi.
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
Hi, On Mon, 2022-12-05 at 09:59 -0500, Brian Reichert wrote:
On Mon, Dec 05, 2022 at 10:50:24AM +0000, Srinidhi B wrote:
Hello List,
We are trying to replace a package in our product that provides the same functionality. We have made changes to our package as documented at - https://en.opensuse.org/openSUSE:Upgrade_dependencies_explanation - but when "zypper patch" command is run, we are receiving a vendor conflict. If we run "zypper patch --allow-vendor-change" then the package dependencies are handled correctly.
Both the vendor names are set to be equivalent.
Changing repositories will trigger this logic. An RPM can have an 'vendor' associated with it, but if that RPM is coming from a different repo than initially installed from, then it's deemed a vendor change.
I'm not too sure of the recent changes in libzypp, and zypper, but I have always had problems if the "vendor" tag actually changed - irrespective of the repository - and if the installed and new vendor are not considered equivalent. That is, if there is no entry for the new vendor in /etc/zypp/vendors.d/ directory.
Mind you, this is based on my own experience, as opposed to having a direct understanding of how zypper is designed to work.
Hence my question is, how can we handle the vendor conflict when replacing a package? Any insights here would be greatly appreciated.
Doesn't '--allow-vendor-change' allow you to do this? Perhaps I'm misunderstanding your question.
Yes, but neither our customers, users, or the existing software management tools (YaST, SUSE Manager, etc.) will pass this option by default. This is why, I'm trying to find an alternate solution that is "clean" and does not prompt the user for interaction. Regards, Srinidhi.
On Monday 05 December 2022 15:59:27 Brian Reichert wrote:
On Mon, Dec 05, 2022 at 10:50:24AM +0000, Srinidhi B wrote:
Hello List,
We are trying to replace a package in our product that provides the same functionality. We have made changes to our package as documented at - https://en.opensuse.org/openSUSE:Upgrade_dependencies_explanation - but when "zypper patch" command is run, we are receiving a vendor conflict. If we run "zypper patch --allow-vendor-change" then the package dependencies are handled correctly.
Both the vendor names are set to be equivalent.
But if the vendor equivalence was set up correctly, --allow-vendor-change should not be needed. openSUSE:Upgrade_dependencies_explanation tells which package dependencies are needed, so your package is considered to be a possible replacement (update candidate) for an installed package. Policies (like the vendorcheck) are applied later, when the set of potential update candidates has to be pruned. Other policies define whether an arch change is allowed, or a (package)name change (i.e. follow renamed packages or not). These are different topics. The dependencies define the set, the policies the pruning.
Changing repositories will trigger this logic. An RPM can have an 'vendor' associated with it, but if that RPM is coming from a different repo than initially installed from, then it's deemed a vendor change.
No, not from a different repo, but from a different vendor! It's true that a repo often contains packages from a single vendor. But the 'vendor' is a property of the package, no matter which repo ships it. The packages vendor string is defined in the .spec file that's used to build the package.
Hence my question is, how can we handle the vendor conflict when replacing a package? Any insights here would be greatly appreciated.
If the packages are not from the same vendor, then you may define a vendor equivalence (in /etc/zypp/vendors.d), appropriate if all packages from this vendor should be allowed to replace each other. Otherwise use --allow-vendor-change with the command the installs the package. In case of doubt, open a bugreport at bugzilla.opensuse.org (component: libzypp or zypper) and attach the solver testcase created by: zypper patch --debug-solver and tell us which package is causing the issue. In the testcase we see the vendors set for the packages and the equivalences defined. To pack the testcase directory: ## cd /tmp tar cvjf zypper-testcase.bz2 /var/log/zypper.solverTestCase In case the testcase exceeds the 10MB limit for bugzilla uploads, you can use 'split' to divide the file into smaller pieces: cd /tmp split -b 10M --additional-suffix=-zypper-testcase.bz2 zypper-testcase.bz2 The created pieces will be named: xaa-zypper-testcase.bz2 xab-zypper-testcase.bz2 xac-... -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres (he/him/his), Engineering & Innovation, ma@suse.com +------------------------------------------------------------------+ SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany, (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman +------------------------------------------------------------------+
participants (3)
-
Brian Reichert -
Michael Andres -
Srinidhi B