Yast2 broken after switch to ruby 3.2 from umbleweed snapshot 20230218
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" the result is: Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Caller: <internal:/usr/lib64/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:88:in `require' Details: Failed to load Module 'PackageSlideShow' due to: Failed to load Module 'Packages' due to: cannot load such file -- solv when trying to start the yast-partitioner, the result is: Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Caller: <internal:/usr/lib64/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:88:in `require' Details: cannot load such file -- storage i checked https://bugzilla.opensuse.org, but didn't find any related bug entry. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development
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?!?
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
On Mon, 2023-02-20 at 16:48 +0100, Rainer Klier wrote:
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.
Urgh... surprised you only run into issues now then. The notification mail does not include all packages being updated in the snapshot. Just as the mail indicates: only packages that are on the DVD are consdiered to create those mails (~ 25% of the package pool) So using this information in order to decide what you think should be updated is flawed from the get-start. Run 'zypper dup' - and let your system be completely updated (all yast modules were rebuilt in that snapshot and thus all yast modules must be updated) Cheers, Dominique
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
On Mon, 2023-02-20 at 16:58 +0100, 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.
Then you should probably reconsider your repo-list (or repo priorities at least)
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):
and 'zypper dup' would clean that stuff up for you.
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?
zypper dup :) | | | V If you scroll far enough: zypper up yast*
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 Mon, 2023-02-20 at 17:11 +0100, Rainer Klier wrote:
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.
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. The more repos, the more likely. You can also use 'zypper lu -a' to see what zypper believes might be updatable generally and work from that list and do the work manually. Good luck
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
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. after updating those packages it works again. thanks to all of you. you guided me into the right direction. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development
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 17:42 schrieb Dominique Leuenberger: > On Mon, 2023-02-20 at 17:33 +0100, Rainer Klier wrote: >> Am 20.02.23 um 17:16 schrieb Dominique Leuenberger: >> 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 ah, ok. so my assumption, that i don't need to update all the ruby 3.1 packages was right. but, then i don't understand why yast didn't auto-select those two packages for update when i was updating yast and ruby? shouldn't there be a dependency, which should have been automaticaly solved by yast, when i was about to upgrade yast and ruby? and maybe I didn't express myself clearly when i wrote before that i searched/selected every package, which was noted in those tumbleweed snapshot email. of course i let yast resolve all dependencies and autoselect all other needed packages. 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. > Depending on what you do on your machine, you can actually "zypper rm - > u ruby3.1" (you likely don't need it anymore) thanks. i did that, and it worked. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development
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
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. if a new version of some package is coming out, i only want to update this, ans all it's dependencies.
want to invest a lot of effort into that.
yes, of course i understand. it's only that most of the time i can rely on these dependencies. they work. i also helped in the past to add some dependencies which were not enabled (systemd needs udev in the same version for example). and for non system critical packages it is not that a problem, you can always start yast and search for packages, you might have overseen. but if the system can't boot any more, or you can't reach software management it is not that easy. but ok, i will form now on remember that ruby-solv and libstorage-ng-ruby are needed for yast. like libyui is also a package that yast relies on... thanks for explanation. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development
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 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.
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. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development namirialLogo _________________________________________________________ Namirial GmbH Phone: +43 7229 88 0 60 - 758 | Mobile: +43 664 610 17 06 Haiderstraße 23 | 4052 Ansfelden | Austria Website: https://www.xyzmo.com/ <https://www.xyzmo.com/> Support: https://www.xyzmo.com/contact/support <https://www.xyzmo.com/contact/support> The sender of this email disclaims any intent to be bound hereby, except where the sender clearly and explicitly provides otherwise. namirialAd
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 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 package source has changed. * The package becomes unresolvable/uninstallable due to another package update and needs to be rebuilt. * Manually triggered rebuilds (often after gcc/glibc updates). The latter are relatively rare, and the former two are roughly what you want anyway. 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.) Aaron [1] <https://build.opensuse.org/projects/openSUSE:Factory/meta>
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
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 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. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Frankenstr. 146 - 90461 Nuernberg - Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nuernberg)
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 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.
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".
On 2023-02-22 18: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.
Maybe you can, but you shouldn't. While the Beta is going on, the Beta should be updated with "zypper dup". When it becomes a final release, then you should switch to "zypper up". TW is considered a permanent Beta in this respect. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.4)
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
Am 22.02.23 um 16:07 schrieb Johannes Meixner:
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.
Leap after GA does usually not see version updates of packages, let alone ABI changes. When it comes to the SLE base, that might in fact be forbidden by policy (but you know that better than I do). Why else would we still be on Python 3.6 or whatever old version that is currently? So even if things like ABI versions are not correctly tracked, there is no way to mess it up. That's different on Tumbleweed, where ABI changes are quite frequent, and happen in numerous places. Leap pre-GA, even after Beta, still "requires" dup to my knowledge, in the sense that it's recommended to use. Basically as long as Leap is open to submit requests and not locked down and limited to maintenance requests.
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.
Sure, I agree that the ABI dependency should be added. I was just arguing that it's not of the highest priority to maintainers, since the "workaround" is simply to do a complete update. Aaron
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 2/22/23 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?
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.
In general, yes. The situation is more complicated for Tumbleweed, though. While there are QA checks even for Tumbleweed, packages tend to be in a less polished state. Additionally, packages in Tumbleweed might get downgraded, which is unheard of in Leap (GA) and SLE (and if it does happen, it's still implemented as an upgrade by means of bumping the epoch, IIRC).
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 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 In such a scenario, A only has an explicit run-time dependency on B, but now image that A also run-time depends upon C, so we'd really have a dep graph like this: A -dep-> B -dep-> C [implicit: A -dep-> C] Since B depends upon C, A will work just fine, but if B drops the dependency upon C in the future, A will very suddenly break and it's not immediately clear why. Because Leap and SLE GA are very conservative regarding package upgrades (which means that most packages are locked to a specific version and only bugs are fixed through backports, i.e., additional patching), such a breakage is unlikely to occur. Factory is way more dynamic and hence more prone to such breakage. The whole point of recommending zypper dup is not to discredit other means of updating software, but to recommend a rather safe way of upgrading the system. If dependencies are correctly recorded and you know which packages to upgrade, picking individual packages and letting the package manager work its magic would certainly be an equivalent upgrade way. Edge cases like package downgrades and dependency bugs break this assumption, though. The other point is that users might have (a lot more) packages installed that won't be mentioned in the automatic mails sent to the list, which means that they will be using outdated and potentially insecure software without even realizing it if just cherry-picking packages. Mihai
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
On Thursday 2023-02-23 08:01, Mihai Moldovan wrote:
In general, yes. The situation is more complicated for Tumbleweed, though. While there are QA checks even for Tumbleweed, packages tend to be in a less polished state. Additionally, packages in Tumbleweed might get downgraded, which is unheard of in Leap (GA) and SLE (and if it does happen, it's still implemented as an upgrade by means of bumping the epoch, IIRC).
Except we don't do epoch, because unlike some other package managers, zypper "knows how to downgrade stuff". (Ironically, that takes the "dup" command. But anyway.) Downgrades would more likely to be in patch form, because it occurs so seldomly (even less so than it does in Tumbleweed).
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
Am 23.02.23 um 00:49 schrieb Aaron Puchert:
Am 22.02.23 um 11:50 schrieb Rainer Klier:
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 that's not in Tumbleweed at all? In the former case I think you're essentially setting
some of them is for having newer versions of packages than Tumbleweed, some of them are because packages are not included in Tumbleweed.
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.
normally there is no problem in cherry picking for example latest version of thunderbird from thunderbird repo. if it doesn't work, i always can disable extra repo, and downgrade thunderbird to the version from Tumbleweed. and this approach works for nearly all those packages from extra repos. the only trouble i ever ran into was when packages from Tumbleweed repo became updated (for example, systemd and yast) and i manually cherry picked them in yast and updated, and then system wasn't booting into grafical runlevel or yast was not any more working, which both then produces the problem, that starting yast and fixing the system by additionally also updating some missed packages is then not possible.... and all those situations, where i ran into trouble was, because there were some packages, which i didn't know there were also needed to be updated, and package management didn't auto-select them. other from that, i never had problems when updating for example thunderbird, firefox, VLC, remmina, or other packages from extra repos.
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?
no. because i don't have an extra repo for yast, but i have one for firefox. but packages for both are exsiting in Tumbleweed repo.
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.
what i mean is, that if there is an update for yast2-fonts, i select this package in yast and update it, rather then running "zypper dup" which then maybe pulls also some updates for things which are not important for me, like for example some updated localization files.
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.
yeah, maybe i can achive what i want/need by using this "--from <alias>" to zypper dup only packages from original Tumbleweed repo. i have to try. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development
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 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). 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
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)
Citeren Rainer Klier <r.klier@namirial.com>:
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 what? For quite a while already, 'zypper dup' will not switch vendors automatically, so I fail to see why configuring different repos would prevent you from doing the right thing. Unless you already have so many conflicting packages, that 'zypper dup' will not be able to resolve the dependencies anymore. In that case, your system is already broken.
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 20.02.23 17:11, Rainer Klier wrote:
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.
should still handle pretty OK with zypper -v dup --no-recommends --no-allow-vendor-change IMHO. At least that works for me always and I also have some repos enabled.
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.
Zypper chokes on the yast2-sound not being available, so you need to specify all yast packages but not yast2-sound. Have fun creating the matching glob expression ;-)
Resolving package dependencies...
so, for me it seems, that i already have all yast packages updated.
No, zypper just errored out. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
* 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
Am 20.02.23 um 17:04 schrieb Mihai Moldovan:
* On 2/20/23 16:58, Rainer Klier wrote:
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 would be cool. i think this would be the best option i have. do you know the syntax for this? -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development
* 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
Am 20.02.23 um 17:24 schrieb Mihai Moldovan:
* 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
great, i think this is what i need.
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.
great! exactly what i would need. thank you very much! -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development
* 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
On Mo, Feb 20 2023 at 16:48:03 +0100, Rainer Klier <r.klier@namirial.com> wrote:
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.
It's probably worth a reminder that yast does not do the dup action when updating, so you should use zypper, packagekit or dnf, last two not being exactly well tested, but __should__ do the right thing. LCP [Jake] https://lcp.world/
* Dominique Leuenberger <dimstar@opensuse.org> [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 <r.klier@namirial.com>:
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
* Rainer Klier <r.klier@namirial.com> [02-20-23 10:37]:
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"
the result is:
Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Caller: <internal:/usr/lib64/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:88:in `require' Details: Failed to load Module 'PackageSlideShow' due to: Failed to load Module 'Packages' due to: cannot load such file -- solv
when trying to start the yast-partitioner, the result is:
Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Caller: <internal:/usr/lib64/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:88:in `require' Details: cannot load such file -- storage
i checked https://bugzilla.opensuse.org, but didn't find any related bug entry.
zypper -v in libyui-qt-pkg16 might solve your difficulty. -- (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
participants (14)
-
Aaron Puchert -
Andrei Borzenkov -
Arjen de Korte -
Carlos E. R. -
Dominique Leuenberger -
Jacob Michalskie -
Jan Engelhardt -
Johannes Meixner -
Mihai Moldovan -
Patrick Shanahan -
Rainer Klier -
Simon Becherer -
Simon Lees -
Stefan Seyfried