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 +------------------------------------------------------------------+