Removing 32-bit libraries safely

Hello, it’s almost 20 years since AMD64 full specification became available and I think, it could be a nice next step to start to drop support for 32-bit obsolete software, the same process like in MacOS. Ubuntu already started it, so I’d like to try. Currently, a lot of 32-bit libs have huge dependencies even on Nvidia drivers or parts of X. I just started and found, samba 32-bit support could be removed without extra dependencies. What do you think, what 32-bit packages could be removed safely?

Why do you want to remove the 32 bit packages? Even though it’s 2020, a lot of programs Linux, Mac and Windows still depend on the 32-bit packages. It’s not like you can just install 64bit packages and expect everything to work perfectly normally.

My recent experience is that most 32-bit libraries are not installed on a clean default install. But if you have been upgrading old systems, then you will get them as upgrades of what is already installed.

Unless you install i586 Tumbleweed, a default openSUSE does not install 32-bit libraries.
The only time you’d have 32-bit libraries installed is if either you purposefully add it to your system or an application includes the library and installs it as part of the application.


Actually, because I’d like to support the future and work of developers by removing support of obsolete software and backports. And also if it’s possible to remove all the **** - it could be better for OS.

I installed Leap 15.2 above old 15.1 so all the packages should be removed/added from scratch (or not).

So, it looks like the only position for now is to wait.

I installed Leap 15.2 above old 15.1 so all the packages should be removed/added from scratch (or not).

If you did that as an install, then it should have reformatted the partition. So there is nothing to remove after that reformat. The new system completely replaces the old.

If you did that as an upgrade, then it will replace older packages with newer ones and remove packages that would otherwise cause conflicts. If you already had 32-bit packages, they would have been upgraded if possible.

Yes, but:

  • There’s still hardware on this planet which has 32-bit registers – the supporting drivers need to use the 32-bit address space to access the hardware registers …

Therefore, until that hardware is replaced with newer versions with 64-bit registers, the 32-bit libraries will continue to be needed – to support the older, no longer maintained drivers …

  • If and only if, there’s hardware on the system which has 32-bit registers …

Yes, of course, if the drivers for the hardware with 32-bit registers, were to be changed such that, the system interface supported 64-bit libraries then, the 32-bit libraries can be removed …

Try “zypper rm ‘*32bit’”

erlangen:~ # zypper rm '*32bit'
Reading installed packages...
Resolving package dependencies...

The following 124 packages are going to be REMOVED:
  cyrus-sasl-32bit cyrus-sasl-crammd5-32bit cyrus-sasl-digestmd5-32bit cyrus-sasl-gssapi-32bit cyrus-sasl-plain-32bit dbus-1-glib-32bit fontconfig-32bit gettext-runtime-32bit glibc-32bit
  glibc-locale-base-32bit krb5-32bit libacl1-32bit libaudit1-32bit libavahi-client3-32bit libavahi-common3-32bit libblkid1-32bit libbrotlicommon1-32bit libbrotlidec1-32bit libbz2-1-32bit
  libcap2-32bit libcom_err2-32bit libcrack2-32bit libcrypt1-32bit libcups2-32bit libcurl4-32bit libdb-4_8-32bit libdbus-1-3-32bit libdcerpc-binding0-32bit libdcerpc0-32bit
  libdevmapper1_03-32bit libeconf0-32bit libexpat1-32bit libfam0-gamin-32bit libffi8-32bit libfontconfig1-32bit libfreetype6-32bit libgcc_s1-32bit libgcrypt20-32bit libgio-2_0-0-32bit
  libglib-2_0-0-32bit libgmodule-2_0-0-32bit libgmp10-32bit libgnutls30-32bit libgobject-2_0-0-32bit libgpg-error0-32bit libhogweed6-32bit libidn2-0-32bit libjansson4-32bit
  libkeyutils1-32bit libldap-2_4-2-32bit libldb2-32bit liblua5_3-5-32bit liblz4-1-32bit liblzma5-32bit libmount1-32bit libndr-krb5pac0-32bit libndr-nbt0-32bit libndr-standard0-32bit
  libndr1-32bit libnetapi0-32bit libnettle8-32bit libnghttp2-14-32bit libnscd1-32bit libnsl2-32bit libnss_nis2-32bit libnss_usrfiles2-32bit libnuma1-32bit libopenssl1_1-32bit
  libp11-kit0-32bit libparted0-32bit libpci3-32bit libpcre1-32bit libpng16-16-32bit libpopt0-32bit libpsl5-32bit libpwquality1-32bit libsamba-credentials0-32bit libsamba-errors0-32bit
  libsamba-hostconfig0-32bit libsamba-passdb0-32bit libsamba-util0-32bit libsamdb0-32bit libsasl2-3-32bit libselinux1-32bit libsmbconf0-32bit libsmbldap2-32bit libssh4-32bit
  libstdc++6-32bit libstdc++6-pp-gcc9-32bit libsystemd0-32bit libtalloc2-32bit libtasn1-6-32bit libtdb1-32bit libtevent-util0-32bit libtevent0-32bit libtextstyle0-32bit libtirpc3-32bit
  libudev1-32bit libunistring2-32bit libuuid1-32bit libverto1-32bit libwbclient0-32bit libxml2-2-32bit libz1-32bit libzstd1-32bit mfc255cwcupswrapper mfc255cwlpr nss-mdns-32bit
  nss_ldap-32bit pam-32bit pam_pwquality-32bit patterns-base-32bit patterns-base-apparmor-32bit patterns-base-base-32bit patterns-base-enhanced_base-32bit patterns-base-minimal_base-32bit
  patterns-base-sw_management-32bit patterns-base-x11-32bit patterns-base-x11_enhanced-32bit perl-base-32bit rpm-32bit samba-client-32bit samba-libs-32bit systemd-32bit

The following 8 patterns are going to be REMOVED:
  32bit apparmor-32bit base-32bit enhanced_base-32bit minimal_base-32bit sw_management-32bit x11-32bit x11_enhanced-32bit

124 packages to remove.
After the operation, 79.4 MiB will be freed.
Continue? [y/n/v/...? shows all options] (y): n
erlangen:~ # 

Packages are tiny and you won’t save much space. Older drivers need them. If you need any of these reinstall.

I maintain computers going back to about 1995. (Many charities etc, run donated computers as there in-house office software). I use old software and modern software to keep these in being.

As others say
"Yes, but:

  • There’s still hardware on this planet which has 32-bit registers – the supporting drivers need to use the 32-bit address space to access the hardware registers …"

So Debian raw, and i586 stuff, are needed to keep them running.

Odd fact. Some machine tools, developed in1990s have a useful life of 40 or more years and here controlling software needs that age / type of computer to work. As machine builder has long been defunct, the old control stuff will not be rewritten to modern computers 64 bit.

For anyone who needs 32bit support, run i586 Tumbleweed.
It should fully support 32bit , is fully patched for security issues and receives a number of modern features.

AFAIK 32bit registers are embedded in 64bit x64, but not utilized unless called.
So, 64bit CPUs (and resource management) should fully support <everything> 32bit might require both directly and indirectly through techniques like thunking, it’s just that typical openSUSE today doesn’t provide everything else to fully support a 32bit system.
Of course vice versa is not true, you won’t run 64bit on a 32bit system without special acrobatics that remap from 64bit to 32bit like PAE.