> I thought the latter was functionally equivalent to “zypper up”,
> (“zypper --help” indicates “up - Update installed packages with newer
> versions”).
There is a difference. An example from last week on my sandbox TW install:
The *-lang packages in the Frameworks5 repo for plasma 5.4.1 already finished building and were published, where the matching * packages hadn’t, so were still 5.4.0. This shows the difference:
zypper ref && zypper up
resulted in “Nothing to do”
Yast2’s Software Manager -> Packages -> All Packages -> Update if a newer version is available
resulted in a long list of failed dependencies for the 5.4.1 *-lang packages reporting the 5.4.1 * packages were’nt available.
That’s not new, it has always been like that. AFAIK
Not if you have additional repos active. In that case zypper looks for the highest available version in all repos ( if you “switched packages” or zypper dup --from thatrepo ). To keep the repo structure intact I use zypper up.
Just tested this on my TW. Despite of a zypper dup --from Packman a zypper dup is going to switch amarok from Packman to the stock version, simply because that one currently has a higher version number. A zypper up shows nothing to do.
I think what you mean is: Not if you want to keep packages that have been sourced from additional repos. Those packages may have been previously installed either using the YaST “switch” or a "zypper dup --from a_specific_repo", for example.
In that case you can use use “zypper up” to keep Amarok installed from Packman. OK, but you had better know what you are doing, because it can miss some changes that the TW snapshot included to be made. It will also avoid conflicts, which again you won’t be aware of.
I prefer to do a plain “zypper dup”, and afterwards manually re-install the odd one out. I haven’t seen the Amarok example, probably because I have Packman repo at a higher priority (lower number). Strangely here Audacity keeps switching to the version from TW’s oss repo, in spite of Packman’s priority.
On 2015-09-17 16:56, Knurpht wrote:
>
> robin_listas;2728643 Wrote:
>> Well, my recommendation for Tumbleweed has always been “zypper dup”.
> Not if you have additional repos active. In that case zypper looks for
> the highest available version in all repos ( if you “switched packages”
> or zypper dup --from thatrepo ). To keep the repo structure intact I use
> zypper up.
But not if you do “export SOLVER_FLAG_DUP_ALLOW_VENDORCHANGE=0”
That’s a good idea when using zypper up for a snapshot upgrade. If it’s just one of those interim Packman only updates I just use P’Kit notifier/updater or zypper up.
Carlos’ suggestion is another option one could use.
It’s particularly good for users hooked on typing longer arcane and experimental commands, and who don’t really use Tumbleweed very often.
Conclusion: there are quite some ways that lead to Rome
Reminder: Look what happened to Rome - the ancient one.
Interesting discussion guys… I’ll probably move to using zypper dup/up for future updates.
The original question of why there is a difference (sometimes) in action between “zypper up” and “yast2 (sw_single) -> Package -> All Packages -> Update if newer version available” still remains; however, that was more out of curiosity.
My impression:
YaST -> Package -> All Packages -> Update if newer version available does what the name suggests: it updates all packages that have a newer version available (in the same repo), i.e. it is the same as clicking on all packages in the list manually and selecting “Update”.
“zypper up” (or dup) has a more complete picture though. It takes all available packages into account, and therefore also notices when a package gets replaced by another one with a different name (e.g. libKF5Server/Client -> kwayland).
I had assumed that yast sw_single was simply a graphical front-end for zypper; that assumption I guess is wrong, hence the difference in actions. So whilst not perhaps a bug per se, yast needs to be a little more intelligent … hmm, a little like me :\
