Hi.
In the last dup zypper wants to install like 50 libabsl new packages. Does anyone know the reason for this?.
Thanks.
Come’on guys. Any clue?. Like many others, I don’t want to install such amount of new packages.
@sidler_bot look at the abseil-cpp changelog?
Sun May 25 11:21:56 UTC 2025
- It seems futile to keep the separation between the lite and the
library package clean, not even internally or for the intended
purpose of aligning with protobuf. Split into single packages per
library and automate.
1 Like
# zypper info abseil-cpp
Loading repository data...
Reading installed packages...
package 'abseil-cpp' not found.
No matching items found.
# zypper se -s abseil
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+---------------------------+---------+----------------+--------+-----------
l | abseil-cpp-devel | package | 20250512.1-1.1 | x86_64 | OSS
l | pybind11-abseil-devel | package | 202402.0-2.9 | x86_64 | OSS
| python311-abseil | package | 2.1.0-2.1 | noarch | OSS
| python311-pybind11_abseil | package | 202402.0-2.9 | x86_64 | OSS
| python312-abseil | package | 2.1.0-2.1 | noarch | OSS
| python312-pybind11_abseil | package | 202402.0-2.9 | x86_64 | OSS
| python313-abseil | package | 2.1.0-2.1 | noarch | OSS
| python313-pybind11_abseil | package | 202402.0-2.9 | x86_64 | OSS
# zypse absl | wc -l
89
#
Sheesh! I’ve locked *absl* for now, waiting to see what doesn’t work without all those new packages.
1 Like
Nothing to see here. I split the two omni packages into many - one for each shared library. This is still the same set of libraries. Zero sheesh required.
1 Like
I don’t recall, when first observed, any removals corresponding to the additions??? Did I simply miss them?
1 Like
Yes, you missed the removal of the two previous library packages.
1 Like
I must have missed something else, and not just about libabsl. Why do packages get split like this when each split-off package is going to be required to be installed anyway due to requirement of the same package(s) that had required the omni? It seems little but a way to create more build, mirror, packages db, and update transaction overhead.
Example: /var/log/zypper.logs are relative monsters, what seems like zillions of lines per package processed, before they get rotated, as much as 12X a journal file. I just did a dup from 20250630 to 20250701.
Before, 65.503MiB:
# ls -gG /var/log/zypper.log
-rw-r----- 1 68685211 Jul 2 14:51 /var/log/zypper.log
# zypper ref
...
# zypper -v dup
...
The following 31 packages are going to be upgraded:
cpp15 15.1.1+git9739-3.1 -> 15.1.1+git9866-1.1
crypto-policies 20250124.4d262e7-3.1 -> 20250124.4d262e7-4.1
curl 8.14.1-3.1 -> 8.14.1-4.1
gpg2 2.5.8-1.1 -> 2.5.8-2.1
libcurl4 8.14.1-3.1 -> 8.14.1-4.1
libev4 4.33-5.4 -> 4.33-6.1
libgcc_s1 15.1.1+git9739-3.1 -> 15.1.1+git9866-1.1
libglslang15 15.3.0-1.1 -> 15.4.0-1.1
libgomp1 15.1.1+git9739-3.1 -> 15.1.1+git9866-1.1
libhogweed6 3.10.1-2.2 -> 3.10.2-1.1
libldap2 2.6.8-2.5 -> 2.6.10-1.1
libldapcpp0 2.6.8-2.3 -> 2.6.10-1.1
libncurses6 6.5.20250621-75.1 -> 6.5.20250628-76.1
libnettle8 3.10.1-2.2 -> 3.10.2-1.1
libnuma1 2.0.19.13.g63e0223-2.1 -> 2.0.19.14.g690a72c-1.1
libshaderc_shared1 2025.3-1.1 -> 2025.3-1.2
libstdc++6 15.1.1+git9739-3.1 -> 15.1.1+git9866-1.1
libudisks2-0 2.10.1-2.3 -> 2.10.1-3.1
libvulkan_intel 25.1.4-418.1 -> 25.1.4-418.2
libvulkan_lvp 25.1.4-418.1 -> 25.1.4-418.2
Mesa-dri 25.1.4-418.1 -> 25.1.4-418.2
Mesa-gallium 25.1.4-418.1 -> 25.1.4-418.2
Mesa-libOpenCL 25.1.4-418.1 -> 25.1.4-418.2
Mesa-libva 25.1.4-418.1 -> 25.1.4-418.2
Mesa-vulkan-device-select 25.1.4-418.1 -> 25.1.4-418.2
ncurses-utils 6.5.20250621-75.1 -> 6.5.20250628-76.1
numactl 2.0.19.13.g63e0223-2.1 -> 2.0.19.14.g690a72c-1.1
openSUSE-release 20250630-3580.1 -> 20250701-3582.1
openSUSE-release-ftp 20250630-3580.1 -> 20250701-3582.1
terminfo-base 6.5.20250621-75.1 -> 6.5.20250628-76.1
udisks2 2.10.1-2.3 -> 2.10.1-3.1
The following product is going to be upgraded:
openSUSE Tumbleweed 20250630-0 -> 20250701-0
The following NEW package is going to be installed:
libSPIRV-Tools-2025_3_rc1 2025.3~rc1-1.1
The following package is going to be REMOVED:
libSPIRV-Tools-2025_2_rc2 2025.2~rc2-1.1
31 packages to upgrade, 1 new, 1 to remove.
Package download size: 60.7 MiB
...
After, 73.916MiB:
# ls -gG /var/log/zypper.log-20250702
-rw-r----- 1 77507058 Jul 2 14:56 zypper.log-20250702
#
It turns out there were a few other transactions after yesterday’s dup, so I dug out the lines for today’s ref and dup:
zypper ref: 1,490 lines, 221,108 bytes.
zypper dup: 75,604 lines, 8,821,847 bytes.
It may not seem like much in the era of multi-TB storage devices, and as storage goes, it’s not so much, but on a V1 running on 3Gbit/s SATA2 HDD of perfectly adequate 200G size it can seem like zypper is hung during and following POST.
1 Like
People can be laconic sometimes, even all the time, what is ok, but I missed here something like:
“… of the two previous library packages, pachage1 and package2.” Just out of my inescapable curiosity.
Mmm, that paragraph in the changelog wouldn’t make me understand why I need to install 50 new packages, to be honest. It’s obscure to me. maybe my bad, but I guess it could have been explained (changelogs can clarify things) in a different clearer way.
Anyway I left the question here because it’s easier if some kind user saves you some time of researching, which in this case and as I said had taken me to a dead end street.
Many thanks to all of you for showing that kindness here. 