Hi folks, Yeasterday I read a long conversation on the mailing list about the correct way to update TW. It seems that even the top gurus of this parish have sort-of agreed to disagree on the topic, but that a consensus seems to favour:
#zypper dup --no-allow-vendor-change
??
There was no mention in the conversation of the updater ‘applet’ which checks daily or whenever, and pops up in the taskbar… Can someone tell me whether simply allowing the updater applet to do its thing is OK? And what “zypper commands” it is actually performing?
My previous habit, on 13.2 and before was to notice the updater telling me that there was updates available and then to do
#zypper ref && zypper up
I get a warning that this is not recommended now, and that I should:
yes. I was also uncertain some month ago and this is what we should now
think as official, and the option no-allow-vendor-change is now default
so go for zypper dup
> me whether simply allowing the updater applet to do its thing is OK? And
> what “zypper commands” it is actually performing?
the updater app will NOT do the right thing. I have brought this up on the mailing list as misleading/dangerous and should be disabled but to no avail.
Yes, “zypper dup --no-allow-vendor-change” from the command line is the only correct way to update TW
“–no-allow-vendor-change” is now the default, so a simple “zypper dup” is sufficient, although there is no harm in still specifying it, indeed I still use it myself from habit.
You could rely upon the updater to inform you.
Other options would be to perform the update on a regular basis (weekly for example), or to follow the factory mailing list https://lists.opensuse.org/opensuse-factory/ for snapshot release announcements.
That was a good habit and still is for the “regular” Leap releases. Actually “zypper up” does also a “ref” if needed, so the “zypper ref” part is overkill.
Basically, “zypper up” only upgrades packages to a higher version, while “zypper dup” also downgrades a package to a lower version if the repo carries a version lower than that installed in the system; this may occasionally happen on Tumbleweed when a troubled package is reverted to a previous version while the newer one gets fixed. When that happens, “zypper up”, or the update applet, will leave you with a broken system on Tumbleweed.
Hope this makes things clearer to you.
It’s been running like this for well over a year. There are a few things to note, though: packman is the only addon repo configured besides the regular tumbleweed repos. No nvidia, no KDE extras, no kernel, nothing. On the rare occasion when I need a package not in tumbleweed+packman, I download it from OBS repo and install it manually. The cronjob will not remove those. Oh, and I have plasma5-pk-updates uninstalled and on the lock list.
I think all of this discussion about vendor change comes from addon repos. If you do not have a ton of addon repos, it is fairly safe to use allow-vendor-change as the worst that can happen is a short term switch from packman to tumbleweed and then back. In fact, I was somewhat put off at the change to making the “no” default. But then, nothing you cannot change with a very small shell script.
I also use “–allow-vendor-change”, though I’m not doing it with a cron job.
As in your case, my only repos are the standard ones plus packman. The standard repos have priority 99, while packman has priority 98. So allowing vendor change should sort things out correctly (prefer packman where there is a choice).
As best I can tell (sometimes running with the “–allow-vendor-change”) is that it will usually make the same vendor changes (if any) either way. But, with “–allow-vendor-change” it won’t give me a conflict resolution dialog.
“zypper dup” still takes repo priorities into account. It prefers a package in a repo of higher priority (lower priority number). Once the priorities are thus sorted out, the next preference is for the highest version number of the package (not the date). But there is also a preference for a package that is currently in the repo over a package that is already installed but is no longer in the repo
you should keep the new default
Here’s how it is working for me:
Some time ago, I followed the advice to switch system packages to “packman”, so as to get the needed codecs.
After that, all packages should be from packman, if there was a packman version (well, not quite, but close enough).
By setting packman to priority 98 instead of the default 99, the zypper priority choices should keep it that way.
Before the change to zypper, I was seeing only occasional vendor changes. In principle, zypper (with the old default) should always prefer a package from packman over a package from the opensuse repos. A vendor change would only occur when either – the package is no longer in packman, or some dependency can only be met by switching vendor to an opensuse repo. These vendor changes were relatively rare.
After the change to zypper (making “–no-allow-vendor-change” the default for Tumbleweed), I was seeing vendor change in exactly those same circumstances. The one difference was that “zypper” now saw those as a conflict and required that I agree individually. So it was easier to just quit out of “zypper” and then do “zypper dup --allow-vendor-change” which made exactly the same vendor changes, but without the conflict dialog.
I am NOT suggesting this to anyone else. It works for me. If I had not changed the priority of the packman repo to 98, then it would be a bad idea. If I were using other special repos, it would probably also be a bad idea.
To say it differently – using “–allow-vendor-change” works fine for me, but only because I have the repo priorities set in such a way as to already prevent the dangerous kind of vendor changes.
