Hi all! I’ve not understood one thing… is there a method to update every package to the latest version, but in a way that automatically recognize which is the correct repository and update from that? (for correct repository i mean the one who has the latest version).
I’m asking it because i often obtain “xxx packages will not update” because the update are in different repository.
If you want every package to be the latest version then you’d probably be better off using Tumbleweed rather than Leap.
But I may have misunderstood your question though…
The openSUSE Heroes and, the SUSE staff who work for the openSUSE project, have published a list of the openSUSE repositories here: <https://en.opensuse.org/Package_repositories>.
Provided that, the packages to be patched or updated are located in these repositories then, “zypper refresh” or, the Packet Manager GUI interface, will refresh the list of packages to be either patched or, updated …
Further update and patch information is documented here: <https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.onlineupdate.you.html>.
BTW, for a Desktop system with a reliable (always available) Ethernet interface, I’m now a fan of automatic updates and patches: <https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.onlineupdate.you.html#sec.onlineupdate.you.automatically>.
That happens because by default the update has “vendor stickiness”, so that packages are updated from the repo they were originally installed from.
To override that you may issue in a terminal:
sudo zypper up --allow-vendor-change
but generally speaking I don’t think this is a good idea. Different repos may use different numbering schemes, so what seems a “newer” package (a higher version number) form a different repo might not be from a newer source file and might break your system if not done properly.
A better choice when you want to upgrade packages from a specific repo (for instance the Packman repo) is:
zypper dup --allow-vendor-change --from <# or alias of the repo you want to upgrade from>
Hope this helps.
When you do a “zypper up,”
You should already pull in the latest version no matter what repo the package may come from… And this is different than “allow vendor change” which looks to me as referencing a particular source of the candidate packages.
When packages are made available, the Maintainers decide whether it’s time to push those packages or let them stay available only as an option. There can be reasons significant or insignificant why collections of packages might not yet be deemed ready as the default and unless there is a reason to do otherwise I put my trust in the Maintainers.
I think if you look more closely at the reason why a package might not be installed right away, it will never say the reason is because it’s from a particular repo, common reasons might be because of an architecture, a particular vendor… and there has to be other reasons not off the top of my head.
It’s likely that the system will assume that if you installed/added a repo to be used, it’s trusted fully as a package source, no more or less than any other repository unless you’ve been messing around with repo priority values (highly not recommended).
TSU
Or, use YaST – “curses” ( user “root” CLI – ‘yast2’ ) or GUI – doesn’t matter … >:)
If you think any of the above comes close to a tiny scratching of the surface of available repositories… You’re mistaken. The number and variety vastly exceeds what can likely be listed on 15 standard size A4 pages by my rough estimation… single spaced.
If you want to go hunting for repositories on your own (or want to point an Internet Search engine at it), I describe this and the Internet location in the openSUSE slide deck I created…
https://slides.com/tonysu/opensuse/#/16
TSU
If you see ‘The following packages will not be updated’ this mostly concerns packages that are in the distribution repos, but also in other repos, where you told the system to install the packages from latter repos. F.e. Packman.
Yes!
That could be an exception to what I posted.
TSU
Really thanks to all for the advices… i will try to do a “zypper up”, and if the problem persist maybe i will let the things how they are… the computer goes normally without problems, so maybe that is not a really problem…
This command lists 22 repos out of the 31 I have enabled and the repo names that show up under zypper up autocomplete are completely different from the Name and URL fields I see in YAST repositories. So now that I have the useful command above, I have no idea how to reference the repo I need to vendor change over to.
I’d like to make a feature request against this issue for Zypper.Unless I’m missing something? Any suggestions?
(sorry can’t edit post after 10m)
UPDATE:
I found a tiny YAST feature that facilitates this. In Software Manager…
Hi
The number on the left is the repo number, or can use the name or alias… or no --from and will change everything to any repo with a later version…
For example;
zypper lr -E
# | Alias | Name | Enabled | GPG Check | Refresh
--+------------------------------------+------------------------+---------+-----------+--------
2 | Local | Local | Yes | ( p) Yes | No
3 | download.opensuse.org-hardware-sdr | Hardware SDR | Yes | (r ) Yes | Yes
5 | download.opensuse.org-oss | Main Repository (OSS) | Yes | (r ) Yes | Yes
6 | download.opensuse.org-tumbleweed | Main Update Repository | Yes | (r ) Yes | Yes
zypper -vvv dup --allow-vendor-change --from 3
or
zypper -vvv dup --allow-vendor-change --from download.opensuse.org-hardware-sdr
or
zypper -vvv dup --allow-vendor-change --from "Hardware SDR"
The following 4 packages are going to be upgraded:
bladeRF-udev 2021.10-54.52 -> 2021.10-54.53 x86_64 Hardware SDR obs://build.opensuse.org/hardware
libbladeRF2 2.4.1-54.52 -> 2.4.1-54.53 x86_64 Hardware SDR obs://build.opensuse.org/hardware
libuhd4_1_0 4.1.0.5-37.7 -> 4.1.0.5-37.8 x86_64 Hardware SDR obs://build.opensuse.org/hardware
uhd-udev 4.1.0.5-37.7 -> 4.1.0.5-37.8 x86_64 Hardware SDR obs://build.opensuse.org/hardware
The -vvv adds verbosity to see what is happening and provide additional feedback.