Why are x86-64 packs not automatically removed when a x86-64-v3 version in installed?

Hello community

I was wondering why the system keeps the x86-64 Version of a package when it installs the same package as x86-64-v3

It caught my eye with that huge update just a few days ago. I think 5 new things where installed on my system and two of them were x86-64-v3 packs. So I checked after the update with Yast and there I see the system keeps both Versions.

Why? Is there a reason?

It was already a pain to get rid of (for me) unnecessary packages and mark them in yast to never install them again (still hoping for a minimal Version of Tumbleweed one day). Would be annoying if we have to do that manually as well with packages we get as a x86-64-v3

I am not a Dev or an expert but it does not make sense to me. Can someone shine some light on this?
Can we uninstall the standard Version. Is it possible to do that automatically? Or with a command that gets rid of duplicated packs?

By the way! Thank you Dev Team for the support of x86-64-v3!
I was blown away by that announcement. Such a great move! Much appreciated! You openSUSES are all amazing :smile:

No, currently the standard build is also required:

$ zypper if --provides --supplements libboost_thread1_81_0-x86-64-v3
Loading repository data...
Reading installed packages...

Information for package libboost_thread1_81_0-x86-64-v3:
Repository     : openSUSE-Tumbleweed-Oss
Name           : libboost_thread1_81_0-x86-64-v3
Version        : 1.81.0-2.1
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 114.3 KiB
Installed      : No
Status         : not installed
Source package : boost-base-1.81.0-2.1.src
Upstream URL   : https://www.boost.org
Summary        : Boost.Thread runtime libraries
Description    :
    This package contains the Boost.Thread runtime library.
Provides       : [2]
    libboost_thread1_81_0-x86-64-v3 = 1.81.0-2.1
    libboost_thread1_81_0-x86-64-v3(x86-64) = 1.81.0-2.1
Supplements    : (libboost_thread1_81_0 = 1.81.0 and patterns-glibc-hwcaps-x86-64-v3)

It supplements, but not replaces anything. If you’re looking for a minimal install, you can configure zypper to skip soft requirements (e.g. recommended and supplements).

$ grep onlyRequires /etc/zypp/zypp.conf
solver.onlyRequires = true
1 Like

Thanks for clarifying.

If you say “currently” I guess/hope this will change in the future?

And is this the case with every v3 package. Libboost_thread was just one that I checked (and liblzo2-2).
There are not many yet but if the support for v3 continues - what I hope - this could add a lot on storage and package count.

I did research about that but many said this is not a good idea cause it could also skip things that are actually required for the system to run properly. And if you say “supplements” and the x86-64-v3 packages are supplements for now, this is probably not the way to go for me.
The recommended way was uninstalling with yast and after that flag the uninstalled programs so ‘zypper dup’ will say this
“The following 57 items are locked and will not be changed by any action:”

So far so good but it was an annoying and time consuming task.

No. The recommended way would have been as described in the official announcement

If for some reason a Tumbleweed user is not interested in the functionality, they can deinstall the patterns-glibc-hwcaps-x86_64_v3 package and “lock it” so that it will not be selected again. Then no optimized versions will be installed in the future on your system.

Only one package to lock…

Sorry you misunderstood. I was talking about the recommended way of keeping a minimal openSUSE install cause of a comparison in my initial post.
I want v3 and read the announcement well.

Did you try to remove any “unnecessary” package, e.g. libboost_thread1_81_0-1.81.0-2.2.x86_64 that you show?

No, I didn’t want to just try it and asking here first. Cause my System is pretty customised (package wise) and works really great so I didn’t want to risk break anything as I am not an expert who can just fix things again.
I know rollback but still…