-32bit-...x86_64 packages.
I noticed a bunch of 32bit packages that often get installed when there is an identically named package but without the -32bit- in the name. What's the difference between the ones that say -32bit- vs. not, and why is a 64bit installation preferring the -32bit- variant of the package. For fun, I installed the 64bit package of the same name and removed the -32bit- package and found no dependency errors. If I want an 'pure' x64 installation, should I just go through my rpm-db and remove all the ones with -32bit- added to the names and replace them with the non-32bit variation? Of NOTE: the -32bit- named packages are NOT the same as packages with the arch=i586. We are talking about all arch x86_64. If I D/l distro files locally, it seems I'm now downloading 2 versions of about 60% of the packages -- ones that I don't need and seem to slow things down (as far as rpm-operations, of which I seem to be doing quite a few lately).
On 12/08/2021 20.31, L A Walsh wrote:
I noticed a bunch of 32bit packages that often get installed when there is an identically named package but without the -32bit- in the name.
What's the difference between the ones that say -32bit- vs. not, and why is a 64bit installation preferring the -32bit- variant of the package.
The -32bit packages are for use by 32 bit applications running in a 64 bit environment. For example, the proprietary acroread package (which will fail for other reasons, but it is the one I remember). So acroread may depend on foosomething-32bit.rpm, but nothing else needs foosomething.rpm so it is not installed.
For fun, I installed the 64bit package of the same name and removed the -32bit- package and found no dependency errors.
My guess: because it was a recommended package, not a depended upon package.
If I want an 'pure' x64 installation, should I just go through my rpm-db and remove all the ones with -32bit- added to the names and replace them with the non-32bit variation? Of NOTE: the -32bit- named packages are NOT the same as packages with the arch=i586. We are talking about all arch x86_64.
If I D/l distro files locally, it seems I'm now downloading 2 versions of about 60% of the packages -- ones that I don't need and seem to slow things down (as far as rpm-operations, of which I seem to be doing quite a few lately).
You probably installed one such 32 bit application (or more) which pulls the 32bit stack in. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On 12.08.21 20:31, L A Walsh wrote:
I noticed a bunch of 32bit packages that often get installed when there is an identically named package but without the -32bit- in the name.
What's the difference between the ones that say -32bit- vs. not, and why is a 64bit installation preferring the -32bit- variant of the package.
The -32bit packages are 32bit, the others are 64bit. That was easy ;-) You need the -32bit packages if you want to run 32bit binaries, e.g. readily compiled stuff downloaded from the internet.
If I D/l distro files locally, it seems I'm now downloading 2 versions of about 60% of the packages -- ones that I don't need and seem to slow things down (as far as rpm-operations, of which I seem to be doing quite a few lately).
zypper rm glibc-32bit will get rid of them (as they probably all depend on glibc-32bit). They will then also not come back with the next zypper dup. It will also get rid of wine if you have that installed. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 2021/08/12 11:54, Stefan Seyfried wrote:
On 12.08.21 20:31, L A Walsh wrote:
I noticed a bunch of 32bit packages that often get installed when there is an identically named package but without the -32bit- in the name.
What's the difference between the ones that say -32bit- vs. not, and why is a 64bit installation preferring the -32bit- variant of the package.
The -32bit packages are 32bit, the others are 64bit.
That was easy ;-)
You need the -32bit packages if you want to run 32bit binaries, e.g. readily compiled stuff downloaded from the internet.
Um...I thought that's what the i586 packages were for. In general, I try not to run 32bit so I don't need duplicate libraries.
On 12/08/2021 20.58, L A Walsh wrote:
On 2021/08/12 11:54, Stefan Seyfried wrote:
On 12.08.21 20:31, L A Walsh wrote:
I noticed a bunch of 32bit packages that often get installed when there is an identically named package but without the -32bit- in the name.
What's the difference between the ones that say -32bit- vs. not, and why is a 64bit installation preferring the -32bit- variant of the package.
The -32bit packages are 32bit, the others are 64bit.
That was easy ;-)
You need the -32bit packages if you want to run 32bit binaries, e.g. readily compiled stuff downloaded from the internet.
Um...I thought that's what the i586 packages were for.
i586 are for a full 32 bit system and processor.
In general, I try not to run 32bit so I don't need duplicate libraries.
Wine. Stefan mentioned it in passing, it is the most common application in a 64 bit system that demands 32 bit libraries because some Windows applications are 32 bit. If you have wine installed, they come from that one. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On 2021/08/12 12:11, Carlos E. R. wrote:
On 12/08/2021 20.58, L A Walsh wrote:
On 2021/08/12 11:54, Stefan Seyfried wrote:
On 12.08.21 20:31, L A Walsh wrote:
I noticed a bunch of 32bit packages that often get installed when there is an identically named package but without the -32bit- in the name.
What's the difference between the ones that say -32bit- vs. not, and why is a 64bit installation preferring the -32bit- variant of the package. The -32bit packages are 32bit, the others are 64bit.
That was easy ;-)
You need the -32bit packages if you want to run 32bit binaries, e.g. readily compiled stuff downloaded from the internet.
Um...I thought that's what the i586 packages were for.
i586 are for a full 32 bit system and processor.
In general, I try not to run 32bit so I don't need duplicate libraries.
Wine. Stefan mentioned it in passing, it is the most common application in a 64 bit system that demands 32 bit libraries because some Windows applications are 32 bit.
If you have wine installed, they come from that one.
Don't have wine installed. I run 32-bit applications on my windows machine. The linux machine is a server to provide services like filesystem, backups, mail, domain (single signon), DNS, web-access (squid). I can even put large win programs (like games) on the server and run them on windows (usually). So in the past, I haven't needed 32bit packages on the server -- and was wondering why I can replace them with the 64-bit packages, manually, and not run into dependency probs. I have zypper setup to not install recommended packages -- just deps. So still don't see why 32-bit packages have been getting installed over their 64-bit alternatives -- it didn't used to happen, so was wondering what might have changed, that's all...
On 12/08/2021 21.21, L A Walsh wrote:
On 2021/08/12 12:11, Carlos E. R. wrote:
On 12/08/2021 20.58, L A Walsh wrote:
On 2021/08/12 11:54, Stefan Seyfried wrote:
If you have wine installed, they come from that one.
Don't have wine installed.
I run 32-bit applications on my windows machine. The linux machine is a server to provide services like filesystem, backups, mail, domain (single signon), DNS, web-access (squid). I can even put large win programs (like games) on the server and run them on windows (usually). So in the past, I haven't needed 32bit packages on the server -- and was wondering why I can replace them with the 64-bit packages, manually, and not run into dependency probs. I have zypper setup to not install recommended packages -- just deps.
So still don't see why 32-bit packages have been getting installed over their 64-bit alternatives -- it didn't used to happen, so was wondering what might have changed, that's all...
Well, try to remove glibc-32bit and see who complains. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On 2021/08/12 12:34, Carlos E. R. wrote:
Well, try to remove glibc-32bit and see who complains.
Haven't reached the end yet, but so far, this is disturbing. Wrote a script (attached), that generates a list of all rpms with '32bit-' in the name (had 138). Try to remove 1st item on list, + capture errors of type: xxxx is needed by (installed) xxxyy Then add xxxyy to the list and try "rpm -e" on the new list. So far, it has taken 2-3 runs for each batch, with 1st run giving me some other rpm, and 2nd run a longer list. Then I ran through and deleted all of them that had no dependencies and am now down to 10 rpms (from 138). Ok, lilo, which hasn't been updated since 2019 depends on these 32bit packages: glibc-32bit-2.33-9.1.x86_64 device-mapper-32bit-1.02.78-20.2.2.x86_64 libselinux1-32bit-3.2-3.1.x86_64 libpcre2-8-0-32bit-10.37-1.1.x86_64 libudev1-32bit-241-1.1.x86_64 I.e. 133 32bit packages were installed as "suggestions", while none of the same-version 64bit ones were installed... I checked and my /etc/zypp/zypp.conf didn't have related files set to off. I thought it was set to that, but it has been set to pull in related since Mar 02,2016. Maybe since I usually have used rpm, I didn't notice how gratuitously it made "suggestions"...
On 14/08/2021 18.11, L A Walsh wrote:
On 2021/08/12 12:34, Carlos E. R. wrote:
Well, try to remove glibc-32bit and see who complains.
Haven't reached the end yet, but so far, this is disturbing. Wrote a script (attached), that generates a list of all rpms with '32bit-' in the name (had 138). Try to remove 1st item on list, + capture errors of type: xxxx is needed by (installed) xxxyy
Then add xxxyy to the list and try "rpm -e" on the new list.
So far, it has taken 2-3 runs for each batch, with 1st run giving me some other rpm, and 2nd run a longer list. Then I ran through and deleted all of them that had no dependencies and am now down to 10 rpms (from 138).
Ok, lilo, which hasn't been updated since 2019 depends on these 32bit packages:
Ah, lilo! Well, there you have the culprit. Nobody is supposed to use it :-p
glibc-32bit-2.33-9.1.x86_64 device-mapper-32bit-1.02.78-20.2.2.x86_64 libselinux1-32bit-3.2-3.1.x86_64 libpcre2-8-0-32bit-10.37-1.1.x86_64 libudev1-32bit-241-1.1.x86_64
I.e. 133 32bit packages were installed as "suggestions", while none of the same-version 64bit ones were installed...
I checked and my /etc/zypp/zypp.conf didn't have related files set to off. I thought it was set to that, but it has been set to pull in related since Mar 02,2016. Maybe since I usually have used rpm, I didn't notice how gratuitously it made "suggestions"...
Weird and difficult to track problems can happen if you don't install suggestions. And they can happen many months after. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On 2021/08/14 10:03, Carlos E. R. wrote:
Ah, lilo! Well, there you have the culprit. Nobody is supposed to use it :-p
--- Well, I suppose 'elilo' is useful for those with the newer bios-boots. But if it still works, why fix it? Next computer likely won't work, but the fact that PC's may no longer be made to support booting w/o a key from MS seems a bit Orwellian.
Weird and difficult to track problems can happen if you don't install suggestions. And they can happen many months after.
--- Yeah, that used to call that bloatware.
On 8/15/21 1:41 AM, L A Walsh wrote:
On 2021/08/12 12:34, Carlos E. R. wrote:
Well, try to remove glibc-32bit and see who complains.
Haven't reached the end yet, but so far, this is disturbing. Wrote a script (attached), that generates a list of all rpms with '32bit-' in the name (had 138). Try to remove 1st item on list, + capture errors of type: xxxx is needed by (installed) xxxyy
Then add xxxyy to the list and try "rpm -e" on the new list.
So far, it has taken 2-3 runs for each batch, with 1st run giving me some other rpm, and 2nd run a longer list. Then I ran through and deleted all of them that had no dependencies and am now down to 10 rpms (from 138).
Ok, lilo, which hasn't been updated since 2019 depends on these 32bit packages:
The maintainer decided to drop lilo last year so unfortunately we can't help you much with that [1]
I.e. 133 32bit packages were installed as "suggestions", while none of the same-version 64bit ones were installed...
I checked and my /etc/zypp/zypp.conf didn't have related files set to off. I thought it was set to that, but it has been set to pull in related since Mar 02,2016. Maybe since I usually have used rpm, I didn't notice how gratuitously it made "suggestions"...
This area has been cleaned up a lot for new installs in the last few years (well certainly since 2016), but if you had one package that needed 32 bit libs rather then 64bit ones it used to pull in alot of other libs as well. But this is largely fixed now that 32bit apps are much less common. 1. https://build.opensuse.org/request/show/811842 -- 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 12/08/2021 21.21, L A Walsh wrote:
If you have wine installed, they come from that one.
---- Don't have wine installed.
Another reason: you block (taboo) something that the system wants. To get around you, it installs the 32 bit version. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
participants (4)
-
Carlos E. R. -
L A Walsh -
Simon Lees -
Stefan Seyfried