You can define a list of repositories having different “vendors” as equivalent by creating a file in the /etc/zypp/vendors.d/ directory with a similar content:
[main]
vendors = suse,opensuse,obs://build.suse.de,Packman,http://packman.links2linux.de
You can find the vendor with YaST (“Versions” tab) or the command line “zypper if <package>”.
You can use any file name, but each file in this directory reflects a group of equivalent vendors.
So, I created a file in /etc/zyyp/vendors.d/ called vendors_tw.
Now this seems to have no effect at all? This is supposed to “allow” zypper to choose the package to update or install from whichever repo has the higher package version number.
The only thing I can think of is the spaces in the repo names?
Vendor stickiness is not about the repo it is about the packages from the repo. If both Repo A and B have a differing version of a package and you install the version from B updates only come from B even if A has a higher version. Because the package is tagged coming from B. You can force a change for a package with Yast or zypper in somepackage --from A or do a complete change of all packages with zypper dup --from A then all packages that are supported by A will come from and be updated from A
This method isn’t doing away with “vendor stickiness” in general - that’s covered in the next section of the page to which I pointed. I literally quoted from the OpenSuSE documentation. I guess I will again:
You can define a list of repositories having different “vendors” as equivalent by creating a file in the /etc/zypp/vendors.d/ directory…
The point is to create a file with a list of “vendors” that are considered by zypper to be equivalent. So if “vendor A” and “vendor B” are in the same list, whichever vendor has the package with the highest version number gets chosen. That’s the point. This method instructs zypper to consider all the repos you place in the file you create as equal - **Disregarding **stickiness.
I didn’t need the concept of vendor stickiness explained - I was trying to figure out why when I follow the official documentation, things don’t work as they appear they should. I mean, hey, maybe zypper has changed and no longer pays attention to the files within the /etc/zypp/vendor.d/ directory. Or maybe I need to reboot before zypper recognizes changes in it’s config. Or maybe the repo names in the file can’t contain spaces or other weird characters? Any ideas relating to that?
Just a guess from me - I can well imagine that spaces could be problematic. Maybe try renaming your repos with ‘_’ character instead, or enclose the affected repo name(s) in the list with single quote perhaps?
My thanks to all that replied! I got rid of the spaces AND the parentheses in the repo names, and that seemed to do the trick. Actually what I did was remove the vendor file I had made. Then I made a new one that was specific to python:
And the procedure acted like I thought it would, it offered to update all python packages in “obs://build.opensuse.org/devel:languages:python” that were newer then the packages in “openSUSE”, without asking to change vendor. Or visa-versa, whichever was newer. Will this work with the other repos? We’ll see.
I apologize if I came off a bit abrasive gogalthorp, it wasn’t personal, I can just be a bit, well, abrasive. But I do appreciate the quick feedback!
Of course though,
As gogalthorpe stated in his original post,
The <default> behavior is for zypper to update to the latest version no matter which repo the latest is in.
Assuming the added repo always has the latest version, then configuring a vendor change to that repo doesn’t accomplish anything.
But, on the tiny and almost inconceivable chance that the added repo <won’t> have the latest version, then the package won’t be upgraded to the latest available.
So,
Bottom line is that if your objective is to always have the latest available, it’s very unlikely that assigning a vendor change will accomplish that.
IMO doing a vendor change like the common Packman example ensures that applications from that specified source consistently uses the supporting packages from that same source.
