I wonder what you are after. AFAIK on Tumbleweed zypper dup defaults to zypper dup --no-allow-vendor-change. Thus repo priority has no influence whatsoever on a zypper dup in TW.
I understand you want me to look at that movie, but you could tell if there is anything there that denies my statement above that repo prios do not influence zypper dup on TW? And isn’t the Title of this thread meaning something like “How do (repo) priorities influence zypper dup on TW”? Or am I misinterpreting your thread title?
I’m not sure that’s quite right. It should still affect where new packages come from. And there are occasional new packages.
In most cases, where there are new packages they probably only exist in one repo. But a new package might have a dependency that it pulls in. And with those priorities it will pull in that dependency from “packman” if it exists there (which is probably appropriate).
zypper dup --no-allow-vendor-change # reported “Nothing to do.”
zypper dup --allow-vendor-change # moved some 30 packages to product repo oss.
zypper dup --no-allow-vendor-change # reported “Nothing to do.”
Thus allowing vendor change on prioritized repos results in a minimal set of changes, which I think is a good thing.
I do not think that is what you proved with this. It shows that allowing Vendor change will install packages from another vendor’s repo. Which is what it allows. And the reason for the switch might be higher version numbers of the packages.
When you want to prove what you want, you have to do allow-vendor-change on a set of repos with all the same priority and again on the same set with different priorities.
BTW, I do not state that using different priorities is bad or useless. I state that it has no consequences for a plain zypper dup (which in TW includes --no-allow-vendor-change). I admit that the special case mentioned by nrickert did not come to my mind though.
I’m pretty sure that depends on what repos you are using and how carefully you have set your priorities.
I actually do use “zypper dup --allow-vendor-change”. However, the only additional repo that I use is “packman” which I have set to priority 98.
Once you add additional repos for special purposes, you have to be careful that you don’t get the wrong library version for software that you are using. My preference is to disable all additional repos other than packman, but to occasionally re-enable to check whether there’s a newer version.
repos providing enhancements to product packages (e.g. packman) have higher proiority, e.g. 90.
repos providing packages not present in the product repos have lower priority, e.g. 100.
I actually do use “zypper dup --allow-vendor-change”. However, the only additional repo that I use is “packman” which I have set to priority 98.
Great to hear that it indeed works.
Once you add additional repos for special purposes, you have to be careful that you don’t get the wrong library version for software that you are using.
I am not sure about this. Anyway I think an enhanced or non product package should or will specify what version it needs. If it doesn’t the product version will do.
My preference is to disable all additional repos other than packman, but to occasionally re-enable to check whether there’s a newer version.
You are even more careful than I am! My objective is to avoid unnecessary questions asked by zypper dup --no-allow-vendor-change. I am confident the current setup will achieve this. Only installing new snapshots will tell whether it actually works.
For a while, I experimented with “krypton” (basically unstable Plasma), installed with repo priorities from the live krypton at that time. And there was one package (I don’t remember which) that kept switching back and forth between the standard repos and the unstable repos. So priorities did not solve all problems. The disallowing of vendor change would have prevented that.
It might not be a matter of packman catching up. I’m guessing that the software has just moved to the openSUSE repos. It was in packman because of a license/patent restriction, but maybe that restriction has expired. At least that’s my guess.
I went ahead with that change.
I then ran into a file conflict
File /usr/lib64/gstreamer-1.0/libgstdvdspu.so
from install of
gstreamer-plugins-bad-1.14.1-1.1.x86_64 (openSUSE-Tumbleweed-Oss)
conflicts with file from package
gstreamer-plugins-bad-orig-addon-1.12.5-4.4.x86_64 (@System)
I told it to continue in spite of the conflict. And then, when the update was done, I uninstalled “gstreamer-plugins-bad-orig-addon-1.12.5-4.4.x86_64”.
You are absolutely right. I was too fast. Thanks for notifying!
I went ahead with that change.
I then ran into a file conflict
File /usr/lib64/gstreamer-1.0/libgstdvdspu.so
from install of
gstreamer-plugins-bad-1.14.1-1.1.x86_64 (openSUSE-Tumbleweed-Oss)
conflicts with file from package
gstreamer-plugins-bad-orig-addon-1.12.5-4.4.x86_64 (@System)
I told it to continue in spite of the conflict. And then, when the update was done, I uninstalled “gstreamer-plugins-bad-orig-addon-1.12.5-4.4.x86_64”.
Went ahead with zypper --verbose dup --allow-vendor-change, got notified of vendor change, no questions asked, no file conflicts. Done.
zypper dup --from 2
Loading repository data…
Reading installed packages…
Computing distribution upgrade…
4 Problems:
Problem: problem with installed package gstreamer-plugins-bad-1.14.1-1.1.x86_64
Problem: problem with installed package gstreamer-plugins-ugly-1.14.1-1.1.x86_64
Problem: problem with installed package gstreamer-plugins-ugly-lang-1.14.1-1.1.noarch
Problem: problem with installed package gstreamer-plugins-bad-lang-1.14.1-1.1.noarch
Problem: problem with installed package gstreamer-plugins-bad-1.14.1-1.1.x86_64
Solution 1: Following actions will be done:
deinstallation of gstreamer-plugins-bad-1.14.1-1.1.x86_64
deinstallation of libcheese8-3.28.0-2.1.x86_64
deinstallation of libcheese-gtk25-3.28.0-2.1.x86_64
deinstallation of gnome-control-center-3.28.1-3.1.x86_64
deinstallation of gnome-contacts-3.28.2-1.1.x86_64
deinstallation of libfarstream-0_2-5-0.2.8-2.2.x86_64
deinstallation of libpurple-2.13.0-4.1.x86_64
deinstallation of pidgin-2.13.0-4.1.x86_64
deinstallation of gnome-shell-search-provider-documents-3.28.0-1.1.x86_64
deinstallation of gnome-shell-search-provider-bijiben-3.28.1-2.1.x86_64
deinstallation of gnome-shell-lang-3.28.2+20180509.e1ed4b25e-1.1.noarch
deinstallation of gnome-shell-extensions-common-3.28.1+20180413.6746061-1.1.noarch
deinstallation of gnome-shell-classic-3.28.1+20180413.6746061-1.1.noarch
deinstallation of gnome-shell-calendar-3.28.2+20180509.e1ed4b25e-1.1.x86_64
deinstallation of gdm-3.28.1-3.1.x86_64
deinstallation of gnome-session-default-session-3.28.1-1.1.x86_64
deinstallation of gnome-tweaks-lang-3.28.1-1.1.noarch
deinstallation of gnome-shell-extensions-common-lang-3.28.1+20180413.6746061-1.1.noarch
deinstallation of gnome-session-3.28.1-1.1.x86_64
deinstallation of gdm-lang-3.28.1-3.1.noarch
deinstallation of gdm-branding-openSUSE-42.3-3.1.noarch
deinstallation of patterns-gnome-gnome_x11-20180321-7.1.x86_64
deinstallation of patterns-gnome-gnome_utilities-20180321-7.1.x86_64
deinstallation of patterns-gnome-gnome_office-20180321-7.1.x86_64
deinstallation of patterns-gnome-gnome_imaging-20180321-7.1.x86_64
deinstallation of gnome-session-wayland-3.28.1-1.1.x86_64
deinstallation of gnome-session-lang-3.28.1-1.1.noarch
deinstallation of patterns-gnome-gnome-20180321-7.1.x86_64
Solution 2: keep obsolete gstreamer-plugins-bad-1.14.1-1.1.x86_64
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c): c
