hi, Am 20.02.23 um 16:42 schrieb Dominique Leuenberger:

On Mon, 2023-02-20 at 16:34 +0100, Rainer Klier wrote:

...

after installing ruby 3.2 from umbleweed snapshot 20230218 most yast modules are broken.

for example, when trying to run "/usr/sbin/yast2 sw_single" Did you properly run 'zypper dup' and update the entire system or did

no, i didn't do it with zypper. i did it with yast. and i didn't update the entire system, but only those packages which are noted in the tumbleweed snapshot email. so, i searched/selected every package, which was noted in those tumbleweed snapshot email, and then let the dependency resolve, and then installed them. i do it this way every time such a tumbleweed snapshot email arrives. i have many repos configured, and always install via yast.

you only update Ruby?!?

i updated (amongst other things) yast and ruby. all dependencies were resolved. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development

Am 20.02.23 um 16:51 schrieb Dominique Leuenberger:

On Mon, 2023-02-20 at 16:48 +0100, Rainer Klier wrote:

...

i have many repos configured, and always install via yast.

...

you only update Ruby?!? i updated (amongst other things) yast and ruby.

all dependencies were resolved.

Run 'zypper dup' - and let your system be completely updated (all yast yeah, with all the repos i have, zypper dup would not work.

so i always update packagesd by hand.

modules were rebuilt in that snapshot and thus all yast modules must be updated)

this is the list of all yast packages (yes, i know, for example, yast2-sound does not exist any more): yast2-sound-4.5.0-1.7.x86_64 yast2-auth-server-4.5.1-1.3.noarch yast2-trans-en_GB-84.87.20230211.83e08d8766-1.1.noarch yast2-users-4.5.3-1.2.x86_64 yast2-4.5.24-1.2.x86_64 patterns-yast-yast2_desktop-20220411-1.3.x86_64 yast2-transfer-4.5.0-1.8.x86_64 yast2-perl-bindings-4.5.1-1.4.x86_64 yast2-nfs-client-4.5.1-1.5.noarch yast2-installation-4.5.15-1.2.noarch yast2-sudo-4.5.0-1.6.noarch yast2-core-4.5.4-1.1.x86_64 yast2-trans-stats-2.19.0-17.25.noarch yast2-control-center-4.5.0-1.4.x86_64 yast2-services-manager-4.5.1-1.4.noarch yast2-qt-branding-openSUSE-84.87.20210910-1.37.noarch yast2-tftp-server-4.5.0-1.6.noarch yast2-slp-4.5.0-1.8.x86_64 yast2-control-center-qt-4.5.0-1.4.x86_64 yast2-vpn-4.5.1-1.3.noarch yast2-country-data-4.5.5-1.2.x86_64 yast2-ycp-ui-bindings-4.5.0-1.5.x86_64 yast2-ruby-bindings-4.5.4-1.2.x86_64 patterns-kde-kde_yast-20221001-103.8.noarch yast2-scanner-4.5.1-1.3.x86_64 yast2-logs-4.5.24-1.2.x86_64 yast2-journal-4.5.3-1.3.noarch yast2-network-4.5.16-1.2.noarch yast2-iscsi-client-4.5.7-1.2.noarch autoyast2-installation-4.5.12-1.2.noarch yast2-sysconfig-4.5.0-1.6.noarch yast2-xml-4.5.0-1.4.x86_64 yast2-snapper-4.5.0-1.6.x86_64 yast2-country-4.5.5-1.2.x86_64 yast2-ldap-4.5.0-1.8.x86_64 yast2-support-4.5.0-1.6.noarch yast2-update-4.5.2-1.2.x86_64 yast2-hardware-detection-4.5.1-1.1.x86_64 yast2-pam-4.5.0-1.6.noarch yast2-python3-bindings-4.5.1-1.2.x86_64 yast2-add-on-4.5.3-1.2.noarch yast2-firewall-4.5.0-1.6.noarch yast2-theme-oxygen-4.5.0-1.6.noarch yast2-ntp-client-4.5.3-1.2.noarch yast2-samba-server-4.5.0-1.6.noarch yast2-x11-4.5.1-1.2.x86_64 yast2-online-update-frontend-4.5.2-1.2.noarch yast2-theme-4.5.0-1.6.noarch yast2-alternatives-4.5.0-1.7.x86_64 yast2-pkg-bindings-4.5.1-1.2.x86_64 patterns-yast-yast2_basis-20220411-1.3.x86_64 yast2-tune-4.5.1-1.3.x86_64 patterns-yast-x11_yast-20220411-1.3.x86_64 yast2-trans-de-84.87.20230211.83e08d8766-1.1.noarch yast2-mail-4.5.0-1.6.noarch yast2-bootloader-4.5.8-1.2.x86_64 yast2-fonts-4.2.1-1.20.x86_64 yast2-storage-ng-4.5.16-1.2.x86_64 yast2-nfs-common-4.5.0-1.6.noarch yast2-apparmor-4.5.0-1.6.noarch yast2-security-4.5.5-1.2.noarch yast2-printer-4.5.2-1.3.x86_64 yast2-proxy-4.5.0-1.6.noarch yast2-samba-client-4.5.3-1.1.noarch yast2-metapackage-handler-4.5.0-1.6.noarch yast2-packager-4.5.15-1.2.x86_64 yast2-online-update-4.5.2-1.2.noarch yast2-auth-client-4.5.4-1.3.noarch yast2-theme-breeze-4.5.0-1.6.noarch yast2-vm-4.5.0-1.6.x86_64 how can i update only all the yast packages? -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development

Am 20.02.23 um 17:01 schrieb Dominique Leuenberger:

On Mon, 2023-02-20 at 16:58 +0100, Rainer Klier wrote:

...

yeah, with all the repos i have, zypper dup would not work. Then you should probably reconsider your repo-list (or repo priorities at least)

yeah, i have to use some packages only available in some extra repos. and some of those repos have some packages which are already present in other repos. so, not so easy to get rif of those extra repos.....

how can i update only all the yast packages? If you scroll far enough: zypper up yast*

i tried zypper up --dry-run yast* result was "No update candidate. The highest available version is already installed" for all the yast packages 'yast2-sound' providing 'yast*' is already installed. Package 'yast2-sound' is not available in your repositories. Cannot reinstall, upgrade, or downgrade. Resolving package dependencies... so, for me it seems, that i already have all yast packages updated. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development

On Monday 2023-02-20 17:16, Dominique Leuenberger wrote:

or zypper trips over a case of a package that does not exist (as said, zypper dup would have cleaned that up) and does not continue the check.

To get your TW install somewhat in line, try at least:

zypper dup -r repo-oss (repo-oss being the alias defined on your TW main repo)

Or rather, zypper dup --from repo-oss

On Mon, 2023-02-20 at 17:33 +0100, Rainer Klier wrote:

Am 20.02.23 um 17:16 schrieb Dominique Leuenberger:

...

On Mon, 2023-02-20 at 17:11 +0100, Rainer Klier wrote:

or zypper trips over a case of a package that does not exist (as said, zypper dup would have cleaned that up) and does not continue the check.

To get your TW install somewhat in line, try at least:

zypper dup -r repo-oss (repo-oss being the alias defined on your TW main repo)

-r will instruct zypper to only take the TW repo into account and ignore all the rest. Some stuff might end up not updatable as 3rd party repos might block stuff.

cool, thanks.

this sounds the right option for me!

this should do the job for me.

but with all your tips i solved it.

thank you very much!

i thought, if all the yast packages are already updated to the latest available versions, maybe i missed one of the ruby packages.

and i tried

zypper up *ruby*

which resulted in

The following 14 packages are going to be upgraded: libruby3_1-3_1 libstorage-ng-ruby ruby-solv ruby3.1-rubygem-abstract_method ruby3.1-rubygem-cfa ruby3.1-rubygem-cheetah ruby3.1-rubygem-fast_gettext ruby3.1-rubygem-gem2rpm ruby3.1-rubygem-nokogiri ruby3.1-rubygem-ruby-augeas ruby3.1-rubygem-ruby-dbus ruby3.1-rubygem-simpleidn ruby3.1-rubygem- unf ruby3.1-rubygem-unf_ext

when updating yast and ruby before, i didn't update those, because i thought as they are ruby 3.1 packages only new rebuilt, i don't need them, and as the yast dependency check didn't automatically mark them for update, i thought they are not needed to be updated.

The relevant ones in this list are not the ruby3.1-*, but rather these two: * libstorage-ng-ruby * ruby-solv Depending on what you do on your machine, you can actually "zypper rm - u ruby3.1" (you likely don't need it anymore)

Am 20.02.23 um 18:04 schrieb Rainer Klier:

so, for example, if in the tumbleweed snapshot email is written, that "GraphicsMagick" ist updated, i enter "magick" in the search-text-box of yast, or when systemd is mentioned in the tumbleweed snapshot email, i enter "systemd" and "udev" in the search-text-box of yast.

then i select all packages and yast autoselects all dependent packages.

this then usually resolves in a list of all packages which i need/want to update.

for some unknown reason, this time the packages "libstorage-ng-ruby" and "ruby-solv" where not auto-selected, which i don't understand.

Let's take ruby-solv: this contains /usr/lib64/ruby/vendor_ruby/3.2.0/x86_64-linux-gnu/solv.so, so it's tied to a specific Ruby version. We could probably add something like Provides: ruby-solv(ruby%{rb_ver}) and then add this as requirement to yast2-packager. In fact we already have requirements there like rubygem(%{rb_default_ruby_abi}:nokogiri), where %{rb_default_ruby_abi} = ruby:3.2.0. But finding and modelling all dependencies is difficult (not all dependencies are as obvious as this), and it's even more difficult to properly test that. (For a start, there might be a lot of combinations when considering partial updates.) Then there is little benefit in making partial updates work, since Tumbleweed will usually not ship new package versions unless it needs to, so you might understand why not many package maintainers want to invest a lot of effort into that. Aaron

On 2023-02-21 08:46, Rainer Klier wrote:

Am 21.02.23 um 02:21 schrieb Aaron Puchert:

...

Am 20.02.23 um 18:04 schrieb Rainer Klier:

...

for some unknown reason, this time the packages "libstorage-ng-ruby" and "ruby-solv" where not auto-selected, which i don't understand.

Let's take ruby-solv: this contains /usr/lib64/ruby/vendor_ruby/3.2.0/x86_64-linux-gnu/solv.so, so it's tied to a specific Ruby version. We could probably add something like

Provides: ruby-solv(ruby%{rb_ver})

Then there is little benefit in making partial updates work, since Tumbleweed will usually not ship new package versions unless it needs to, so you might understand why not many package maintainers

yes, but i don't want to run a full system update all the time.

Then don't use TW. :-) The only supported update mode for TW is "zypper dup". If you use something different, even YaST, you can bump into strange problems. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)

Am 21.02.23 um 12:27 schrieb Rainer Klier:

Am 21.02.23 um 11:16 schrieb Carlos E. R.:

...

On 2023-02-21 08:46, Rainer Klier wrote:

...

Am 21.02.23 um 02:21 schrieb Aaron Puchert:

...

Then there is little benefit in making partial updates work, since Tumbleweed will usually not ship new package versions unless it needs to, so you might understand why not many package maintainers

yes, but i don't want to run a full system update all the time.

you could use the package "tumbleweed-cli" then you use the command: "tumbleweed" the command "tumbleweed init" will stuck your tumbleweed at a static repo. of course only a short time (the last 20 snapshoots.) so you have the posibility to use yast between the tumbleweed "dup" as long as your system ist on the stucking repo. after about 2-3 weeks, it will be gone and you have to dup. (in this case: "tumbleweed update") -> at the moment 20230130 is the oldest. simoN

...

Then don't use TW. :-) The only supported update mode for TW is "zypper dup".

i didn't know, that on TW this is the only supported update mode.

i am using yast since a long time.

-- B e c h e r e r GmbH Sondermaschinenbau Mauermatten Strasse 22 79183 Waldkirch Germany Tel.: (+49) (0)7681 3134 Fax: (+49) (0)7681 4378 Mail: info@becherer.de Web: www.becherer.de USt-ID-Nr.: DE 814912198 Registergericht: Freiburg HRB 701860 Geschaeftsfuehrer: Dipl.-Ing. (FH), EWE Simon H. Becherer Gerichtsstand / Sitz: Waldkirch Es gelten ausschliesslich unsere allgemeinen Liefer- und Zahlungsbedingungen / Einkaufsbedingungen: www.becherer.de/AGB ----------------------------------------------- - Das ist die vorlaeufig endgueltige Version! - Herbert C. Maier Dipl.-Ing. (FH) -----------------------------------------------

Am 22.02.23 um 01:45 schrieb Aaron Puchert:

Am 21.02.23 um 08:46 schrieb Rainer Klier:

...

Am 21.02.23 um 02:21 schrieb Aaron Puchert:

...

Then there is little benefit in making partial updates work, since Tumbleweed will usually not ship new package versions unless it needs to, so you might understand why not many package maintainers

yes, but i don't want to run a full system update all the time.

if a new version of some package is coming out, i only want to update this, ans all it's dependencies.

Here I can't quite follow: what other updates would there be? Note that Factory is build with rebuild="local" [1], so packages aren't rebuild all the time. You get package updates for roughly three reasons:

But maybe this isn't about Factory itself but rather third-party repositories? (In which case others on the thread mentioned a flag that might help.)

yes, often the packages i want to update are coming from extra repositories. i have, for example, extra repos configured for Xorg, libreoffice, KDE, kernel, extra kernel-modules (wlan, vbox) most of the time updating packages from those repos don't produce problems. but there are also sometimes packages listed in those tumbleweed snapshot emails, which are only existing in the main tumbleweed repos, or for which i don't have an extra repo. for example system packages like systemd, yast, glibc and if, for example, there are new packages available for yast or systemd, i select in yast software manager all related packages to be updated. and i don't want to update the whole tumbleweed system, only because for example yast2-fonts is released in a new version. that's the main reason for using that approach. so i select everything, which is needed to be able to update, and i trust/rely that yast resolves all dependencies and auto-selects all those packages which are additional needed. most of the time this approach works. but sometimes (like this time, when ruby was updated/upgraded the dependency auto-select didn't also mark libstorage-ng-ruby and ruby-solv), that fails. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development

On 2023-02-22 16:07, Johannes Meixner wrote:

Hello,

On 2023-02-22 11:50, Rainer Klier wrote (excerpt)

...

if, for example, there are new packages available for yast or systemd, i select in yast software manager all related packages to be updated.

and i don't want to update the whole tumbleweed system, only because for example yast2-fonts is released in a new version. that's the main reason for using that approach.

so i select everything, which is needed to be able to update, and i trust/rely that yast resolves all dependencies and auto-selects all those packages which are additional needed.

most of the time this approach works.

but sometimes (like this time, when ruby was updated/upgraded the dependency auto-select didn't also mark libstorage-ng-ruby and ruby-solv), that fails.

I am wondering why it seems on Tumbleweed "zypper dup" is told here to be the only right way to update something?

Shouldn't package management work same on Tumbleweed and openSUSE Leap and SLES and others so that the user can select an arbitrary package to be updated (when a package update is available) and then the package management would do "the right thing" to ensure that afterwards the system is again in an consistent state regarding package dependencies.

I don't remember the rationale, but it goes back many years. Before TW existed, and zypper was being developed, and the "dup" option was added, initially to do a full version distribution upgrade. The problem is that this tidbit should be in clear, big adverts, in several Tumbleweed pages. People forget, and others disbelieve ;-) I'm sorry, I don't have a link to a page explaining this.

I think in this particular case here package management did "the right thing" so afterwards the system was again in an consistent state regarding package dependencies.

But because afterwards things did no longer work the root cause was likely inproperly defined package dependencies so it seems there is a bug of missing package dependencies.

IMHO, it is not a bug if you are expected to not use "zypper up" but "zypper dup". -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)

On 22.02.2023 20:26, Jan Engelhardt wrote:

On Wednesday 2023-02-22 16:07, Johannes Meixner wrote:

...

I am wondering why it seems on Tumbleweed "zypper dup" is told here to be the only right way to update something?

You can also use dup on Leap. After all, syncing to $blessed repository makes your local machine $blessed by definition, just like on TW.

The stress was on "dup", not on "Tumbleweed".

hi, Am 22.02.23 um 16:07 schrieb Johannes Meixner:

Hello,

On 2023-02-22 11:50, Rainer Klier wrote (excerpt)

...

so i select everything, which is needed to be able to update, and i trust/rely that yast resolves all dependencies and auto-selects all those packages which are additional needed.

most of the time this approach works.

but sometimes (like this time, when ruby was updated/upgraded the dependency auto-select didn't also mark libstorage-ng-ruby and ruby-solv), that fails.

Shouldn't package management work same on Tumbleweed and openSUSE Leap and SLES and others so that the user can select an arbitrary package to be updated (when a package update is available) and then the package management would do "the right thing" to ensure that afterwards the system is again in an consistent state regarding package dependencies.

this is exactly what i was talking about, and what i was expecting.

I think in this particular case here package management did "the right thing" so afterwards the system was again in an consistent state regarding package dependencies.

But because afterwards things did no longer work the root cause was likely inproperly defined package dependencies so it seems there is a bug of missing package dependencies.

this is exactly how it felt for me. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development

On 2/23/23 01:37, Johannes Meixner wrote:

Hello,

On 2023-02-22 11:50, Rainer Klier wrote (excerpt)

...

if, for example, there are new packages available for yast or systemd, i select in yast software manager all related packages to be updated.

and i don't want to update the whole tumbleweed system, only because for example yast2-fonts is released in a new version. that's the main reason for using that approach.

so i select everything, which is needed to be able to update, and i trust/rely that yast resolves all dependencies and auto-selects all those packages which are additional needed.

most of the time this approach works.

but sometimes (like this time, when ruby was updated/upgraded the dependency auto-select didn't also mark libstorage-ng-ruby and ruby-solv), that fails.

I am wondering why it seems on Tumbleweed "zypper dup" is told here to be the only right way to update something?

Shouldn't package management work same on Tumbleweed and openSUSE Leap and SLES and others so that the user can select an arbitrary package to be updated (when a package update is available) and then the package management would do "the right thing" to ensure that afterwards the system is again in an consistent state regarding package dependencies.

Technically every Tumbleweed update is the same as doing an Upgrade from Leap 15.3 to Leap 15.4 because here you are getting a new version of the distro where as a Leap update is just applying delta's from an update repo.

I think in this particular case here package management did "the right thing" so afterwards the system was again in an consistent state regarding package dependencies.

But because afterwards things did no longer work the root cause was likely inproperly defined package dependencies so it seems there is a bug of missing package dependencies.

Yep the main downside to doing things differently is eventually you'll find bugs that no one else has discovered yet, i'm sure there are a bunch of places where bugs like this exist that occasionally pop up when someone does partial updates or skips recommends. Yes we should fix them if we find them but we don't generally have a good way of finding them. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Thu, 2023-02-23 at 08:01 +0100, Mihai Moldovan wrote:

This is also true and nobody did object. That's clearly a case of missing run-time dependencies. This said, getting run-time dependencies right/complete is an extremely difficult task and maintainers often get them wrong. Fortunately, the build environments are pretty good at scanning for run-time dependencies and automatically add them, but the capabilities are mostly limited to shared libraries. In the special case discussed here, dependencies on packages providing interpreted scripts were missing and that was obviously not caught at build time - either because the build does not need the packages in the first place (which is naturally different from normal usage) or because the dependency was transitive, i.e., pulled in by a different build dependency.

Transitive dependencies are especially difficult to track. Image an explicit dependency graph such as:

A -dep-> B -dep-> C

I'm afraid it is even more complex than what you describe. Let's look at exactly the YaST case reported in this thread: OP started 'yast2 sw_single' - which in fact is yast2-packager packege. In yast2-packager, there is a dependency: ruby-solv yast2-ruby-bindings >= 1.0.0 Now, this is true - BUT 'incomplete' - as in fact, yast2-packager would require a yast2-ruby-bindings that was built with the same ruby interpreter version. Of course we're just talking rebuilds, so the version of the package did not change (in fact there was not even a source change). The dependency was thus fullfilled with the 'old' Ruby 3.1 built package, but could not work, as yast2-storage is a ruby3.2 code, trying to load modules. For this to work, the yast packages would need to simulate what all gem-packages do, namely: Provides: rubygem(ruby:3.2.0:yast2-ruby-bindings) Then yast2-sw_single could require this symbol and replace 3.2.0 API- version used to build yast2-packager. The format for the provides could be different of course - that one is just for visualization as it is used exactly by this by all ruby modules This is a speciality of interpreted languages to take into account - but does make sense. (same issue happens with python fwiw) Cheers, Dominique

Am 22.02.23 um 01:45 schrieb Aaron Puchert:

...

But maybe this isn't about Factory itself but rather third-party repositories? (In which case others on the thread mentioned a flag that might help.)

yes, often the packages i want to update are coming from extra repositories.

i have, for example, extra repos configured for Xorg, libreoffice, KDE, kernel, extra kernel-modules (wlan, vbox) That sounds like a lot. Are these all devel repos? What is the reason for that? Having even newer versions than Tumbleweed or having software

Am 22.02.23 um 11:50 schrieb Rainer Klier: that's not in Tumbleweed at all? In the former case I think you're essentially setting yourself up for trouble, especially with so many repositories. In the latter case I'd recommend giving these repos higher priority (numerically, which means a lower priority), so that packages from these repos are only used if the software isn't in Tumbleweed.

most of the time updating packages from those repos don't produce problems.

but there are also sometimes packages listed in those tumbleweed snapshot emails, which are only existing in the main tumbleweed repos, or for which i don't have an extra repo. Well, shouldn't this be the general case? Or are you not actually running Tumbleweed but a union of development repositories? and i don't want to update the whole tumbleweed system, only because for example yast2-fonts is released in a new version. that's the main reason for using that approach.

What do you mean with "update the whole tumbleweed system"? If only yast2-fonts has been released in a new version, you should generally only get an update for that if you do "zypper dup". Unless of course you're using development repositories, which rebuild whenever any dependency changes. For what it's worth, I'm very sympathetic to keeping updates small. But you should be able to get that with "zypper dup" and not have to manually select packages. Aaron

On 2023-02-22 01:45, Aaron Puchert wrote:

Am 21.02.23 um 08:46 schrieb Rainer Klier:

...

Am 21.02.23 um 02:21 schrieb Aaron Puchert:

...

Then there is little benefit in making partial updates work, since Tumbleweed will usually not ship new package versions unless it needs to, so you might understand why not many package maintainers

yes, but i don't want to run a full system update all the time.

if a new version of some package is coming out, i only want to update this, ans all it's dependencies.

Here I can't quite follow: what other updates would there be? Note that Factory is build with rebuild="local" [1], so packages aren't rebuild all the time. You get package updates for roughly three reasons:

The thing that "zypper dup" does is that what you get has to be the same version as the repo has, no matter if it is upgrade or downgrade. And it checks every package you have, plus dependencies of the resulting list. It can also remove not maintained (or perhaps obsoleted?) packages. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)

On 2023-02-22 15:46, Mihai Moldovan wrote:

* On 2/22/23 15:16, Carlos E. R. wrote:

...

The thing that "zypper dup" does is that what you get has to be the same version as the repo has, no matter if it is upgrade or downgrade. Thank you for bringing that up.

Unfortunately, Tumbleweed rarely contains package downgrades. While I frown upon that whenever I see it happening, they happen nonetheless (mostly to fix issues brought in by a former upgrade, I presume).

Package downgrades as such can be valid thing, and there are good reasons for doing them. For instance, sometimes, the versioning scheme of a package changes, and while that syntactically (i.e., vercmp) would a downgrade, it can still be an upgrade (e.g., the upstream developer might have used a date-based versioning scheme in the past and then switched to semantic versioning, resetting the previous version to a much lower number).

Or simple package renumbering.

The proper way to handle such situations is to bump the epoch and thus force a proper syntactic version upgrade, but Tumbleweed seems to forgo this approach at times. Probably because users are expected to dist-upgrade anyway...

I don't know how YaST handles this situation, but my gut feeling tells me that it probably skips downgrades unless they are explicitly forced. Yet another way to break (parts of) the system.

Mihai

-- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)

On Mon, 2023-02-20 at 17:11 +0100, Rainer Klier wrote:

Am 20.02.23 um 17:01 schrieb Dominique Leuenberger:

...

...

yeah, with all the repos i have, zypper dup would not work. Then you should probably reconsider your repo-list (or repo

On Mon, 2023-02-20 at 16:58 +0100, Rainer Klier wrote: priorities at least)

yeah, i have to use some packages only available in some extra repos.

and some of those repos have some packages which are already present in other repos.

so, not so easy to get rif of those extra repos.....

work together with the respective repo owners/maintainers to get their packages into Tumbleweed and fix the issue for everybody.

* On 2/20/23 16:58, Rainer Klier wrote:

...

Run 'zypper dup' - and let your system be completely updated (all yast yeah, with all the repos i have, zypper dup would not work.

so i always update packagesd by hand.

Using zypper, you can disable or enable specific repositories for a single operation only. Doing that would let you run dup for the core repositories only (since TW only has one repository, if I remember correctly, that would be really easy to do) and correctly upgrade to the new Tumbleweed snapshot.

this is the list of all yast packages (yes, i know, for example, yast2-sound does not exist any more):

[...]

how can i update only all the yast packages?

That's essentially asking humans on a mailing list to do the job a high-level package manager is supposed to do and usually does effortlessly. Mihai

* On 2/20/23 17:15, Rainer Klier wrote:

this would be cool.

i think this would be the best option i have.

do you know the syntax for this?

zypper(8) documents such things, but in general: zypper dup --from <alias> [--from <alias> ...] should just do the trick, and keep other repositories visible to the resolver WITHOUT pulling package upgrades off them. The repository alias is included in the output of zypper repos On my TW VM, with such output (this is only an example, your system might and will probably look differently, since most people have not enabled debug or source repositories): # | Alias | Name | Enabled | GPG Check | Refresh --+------------------------------------------------+-----------------------------------------------------------------------+---------+-----------+-------- 1 | download.opensuse.org-non-oss | Main Repository (NON-OSS) | Yes | (r ) Yes | Yes 2 | download.opensuse.org-oss | Main Repository (DEBUG) | Yes | (r ) Yes | Yes 3 | download.opensuse.org-oss_1 | Main Repository (Sources) | Yes | (r ) Yes | Yes 4 | download.opensuse.org-oss_2 | Main Repository (OSS) | Yes | (r ) Yes | Yes 5 | download.opensuse.org-tumbleweed | Main Update Repository | Yes | (r ) Yes | Yes [...] [other repositories I'm not at liberty to disclose] I'd use something like zypper dup --from download.opensuse.org-non-oss --from download.opensuse.org-oss --from download.opensuse.org-oss_1 --from download.opensuse.org-oss_2 --from download.opensuse.org-tumbleweed to only upgrade packages from Tumbleweed, while letting the resolver *see* the other package repositories as well, so that it can resolve dependency issues automatically. If there are still dependency issues, it will prompt anyway. Mihai

* On 2/20/23 16:48, Rainer Klier wrote:

[...] and i didn't update the entire system, but only those packages which are noted in the tumbleweed snapshot email.

so, i searched/selected every package, which was noted in those tumbleweed snapshot email, and then let the dependency resolve, and then installed them.

i do it this way every time such a tumbleweed snapshot email arrives.

Why would you do that? The snapshot mail explicitly mentions that it only contains changes to packages on the installation media, so only updating a subset is a sure-fire way to break your system in hard to diagnose ways. Please run zypper dup properly as mentioned by other people, or let YaST handle the full upgrade. Mihai

* Dominique Leuenberger [02-20-23 10:43]:

On Mon, 2023-02-20 at 16:34 +0100, Rainer Klier wrote:

...

hi,

after installing ruby 3.2 from umbleweed snapshot 20230218 most yast modules are broken.

for example, when trying to run "/usr/sbin/yast2 sw_single"

Did you properly run 'zypper dup' and update the entire system or did you only update Ruby?!?

appears libyui-qt-pkg16 was not automatically installed during "dup" -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

Am 20.02.23 um 16:48 schrieb Arjen de Korte:

Citeren Rainer Klier :

...

after installing ruby 3.2 from umbleweed snapshot 20230218 most yast modules are broken.

Works fine here. You ran 'zypper dup' to update Tumbleweed I presume?

no, i only updated (amongst other things) yast and ruby with yast software management all dependencies were resolved -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development