why 32-bit pkgs? "inferior arch i586" offered by zypper - why?
I thought opensuse wasn't going to support a 32-bit release anymore? Even if, often, when I'm looking through a batch of proposed solutions, I'll see: "nothing provides 'XXYZ', so we wanna remove about 20 x86_64 products and change architecture to i586 despite the inferior architecture". Huh?... why would it not be able to use an x86_64 version of the same? It's sorta annoying to have it keep offering to downgrade archs as a solution. I don't mind alt-vendors being suggested, but downgrading archs, not so keen on. I noticed the solver is getting ideas from a huge number of i586 packages in the daily TW. Why so many/why are they there? Don't suppose there is any easy way to block inferior archs being offered as suggestions? Seems like the only way might be to prune the i586 packages out of the package list so the solver doesn't get confused? Ug.
On Tue, 2021-04-20 at 02:15 -0700, L A Walsh wrote:
I thought opensuse wasn't going to support a 32-bit release anymore?
Tumbleweed still has full support for i586, and I intend to keep that for as long as possible.
Even if, often, when I'm looking through a batch of proposed solutions, I'll see: "nothing provides 'XXYZ', so we wanna remove about 20 x86_64 products and change architecture to i586 despite the inferior architecture".
You decribe the consequence of what zypper wants to do - but fail to provide more information as to WHY it would want to do so. In most cases, it is some noarch package with a fixed version-release requires, that happened to have failed on x86_64 (or i586); OBS is only publishing one of the noarch packages, which means the rebuild from x86_64 binaries might be there, but the i586 failed to build, still having the old noarch in place. 'vim' for example is a package which I know of having this problem over and over (randomly, the build fails on either arch). so, zypper finds a noarch package with a fixed set of requirements, but in order to satisfy it, arch would need to be changed, as the native arch has a rebuild with different version-release counters. to be sure:more details are needed; but this should get you on the track to find out basedon the suggestions zypper is doing. Cheers, Dominique
On 20/04/2021 11.15, L A Walsh wrote:
I thought opensuse wasn't going to support a 32-bit release anymore?
Even if, often, when I'm looking through a batch of proposed solutions, I'll see: "nothing provides 'XXYZ', so we wanna remove about 20 x86_64 products and change architecture to i586 despite the inferior architecture".
Huh?... why would it not be able to use an x86_64 version of the same? It's sorta annoying to have it keep offering to downgrade archs as a solution. I don't mind alt-vendors being suggested, but downgrading archs, not so keen on.
No, that's simply a side "misfeature" of the solver. If there were no 32 bit versions, the solver will simply say there is no solution (as would happen with Leap). You basically have to interpret what it says and translate to "no solution". So, to ask here, post the actual message error of what it is trying to install that it is missing. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
I guess he talks about package mess with packman's ffmpeg which is arrived today. I "updated" to packmans ffmpeg-4-4.4-4.1 which is only provided in pacman repo (this version is staging mmedia:libs, while TW - is 4.3.2-1.1) and got all my multimedia codecs dead. On 2021-04-20 19:28, Carlos E.R. wrote:
On 20/04/2021 11.15, L A Walsh wrote:
I thought opensuse wasn't going to support a 32-bit release anymore?
Even if, often, when I'm looking through a batch of proposed solutions, I'll see: "nothing provides 'XXYZ', so we wanna remove about 20 x86_64 products and change architecture to i586 despite the inferior architecture".
Huh?... why would it not be able to use an x86_64 version of the same? It's sorta annoying to have it keep offering to downgrade archs as a solution. I don't mind alt-vendors being suggested, but downgrading archs, not so keen on.
No, that's simply a side "misfeature" of the solver.
If there were no 32 bit versions, the solver will simply say there is no solution (as would happen with Leap). You basically have to interpret what it says and translate to "no solution".
So, to ask here, post the actual message error of what it is trying to install that it is missing.
Personally, I still need a lot of 32-bit pkgs because 32-bit wine applications need them. Best, Xu -- Xu Zhao nuk.zhao@utoronto.ca On Tue, 20 Apr 2021, at 5:15 AM, L A Walsh wrote:
I thought opensuse wasn't going to support a 32-bit release anymore?
Even if, often, when I'm looking through a batch of proposed solutions, I'll see: "nothing provides 'XXYZ', so we wanna remove about 20 x86_64 products and change architecture to i586 despite the inferior architecture".
Huh?... why would it not be able to use an x86_64 version of the same? It's sorta annoying to have it keep offering to downgrade archs as a solution. I don't mind alt-vendors being suggested, but downgrading archs, not so keen on.
I noticed the solver is getting ideas from a huge number of i586 packages in the daily TW. Why so many/why are they there?
Don't suppose there is any easy way to block inferior archs being offered as suggestions? Seems like the only way might be to prune the i586 packages out of the package list so the solver doesn't get confused? Ug.
On 2021/04/20 02:28, Carlos E.R. wrote:
On 20/04/2021 11.15, L A Walsh wrote:
I thought opensuse wasn't going to support a 32-bit release anymore?
Even if, often, when I'm looking through a batch of proposed solutions, I'll see: "nothing provides 'XXYZ', so we wanna remove about 20 x86_64 products and change architecture to i586 despite the inferior architecture".
Huh?... why would it not be able to use an x86_64 version of the same? ...
No, that's simply a side "misfeature" of the solver.
If there were no 32 bit versions, the solver will simply say there is no solution (as would happen with Leap). You basically have to interpret what it says and translate to "no solution".
Well, that's "sorta" what I thought, which is "sorta" what I wanted...since I don't have any of the 586 binaries pulled down, but the solver is only going by what is being offered in primary.xml.gz which has a bunch of i586 items. Seems like from what Dominique is saying that I should only see those i586 packages when the equivalent x86_64 package isn't listed as even an option in the "primary.xml.gz" file, which, if I understand things, *SHOULD* be relatively rare?... Hmmmmm....rt? hmmm....
On 20/04/2021 21.37, L A Walsh wrote:
On 2021/04/20 02:28, Carlos E.R. wrote:
On 20/04/2021 11.15, L A Walsh wrote:
I thought opensuse wasn't going to support a 32-bit release anymore?
Even if, often, when I'm looking through a batch of proposed solutions, I'll see: "nothing provides 'XXYZ', so we wanna remove about 20 x86_64 products and change architecture to i586 despite the inferior architecture".
Huh?... why would it not be able to use an x86_64 version of the same? ...
No, that's simply a side "misfeature" of the solver.
If there were no 32 bit versions, the solver will simply say there is no solution (as would happen with Leap). You basically have to interpret what it says and translate to "no solution".
Well, that's "sorta" what I thought, which is "sorta" what I wanted...since I don't have any of the 586 binaries pulled down, but the solver is only going by what is being offered in primary.xml.gz which has a bunch of i586 items.
Seems like from what Dominique is saying that I should only see those i586 packages when the equivalent x86_64 package isn't listed as even an option in the "primary.xml.gz" file, which, if I understand things, *SHOULD* be relatively rare?...
Yes, pretty rare. Something broke and the packages that you need failed to build. So, don't update today. Welcome to Tumbleweed :-D
Hmmmmm....rt? hmmm....
-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Am Dienstag, 20. April 2021, 11:37:15 CEST schrieb Konstantin Voinov:
I guess he talks about package mess with packman's ffmpeg which is arrived today. I "updated" to packmans ffmpeg-4-4.4-4.1 which is only provided in pacman repo (this version is staging mmedia:libs, while TW - is 4.3.2-1.1) and got all my multimedia codecs dead.
The problem is, that packman "inherits" the version from multimedia:libs, and the submit to Factory took a little longer this time. Factory has to rebuild all packages depending on it, which are quite a few (ignoring the fallout). I'm eagerly awaiting the ffmpeg-4 update from factory as well for 20+ installations (since last Friday..). You should have noticed suspicious notes about dependencies, that could not been resolved and such. A note to everybody: if you use more than one repo and update via PackageKit, here is the cure: zypper rm PackageKit. Use zypper. Read carefully. Decide. Cancel is an option. Cheers, Pete
On 20/04/2021 22.50, Hans-Peter Jansen wrote:
A note to everybody: if you use more than one repo and update via PackageKit, here is the cure: zypper rm PackageKit.
You have to lock it out, or it will be reinstalled.
Use zypper. Read carefully. Decide. Cancel is an option.
-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
* Carlos E.R.
On 20/04/2021 22.50, Hans-Peter Jansen wrote:
A note to everybody: if you use more than one repo and update via PackageKit, here is the cure: zypper rm PackageKit.
You have to lock it out, or it will be reinstalled.
Use zypper. Read carefully. Decide. Cancel is an option.
no, locking is not necessary on my Tumbleweed systems. -- (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 freenode
Patrick Shanahan composed on 2021-04-20 17:25 (UTC-0400):
* Carlos E.R. [04-20-21 16:56]:
Hans-Peter Jansen wrote:
A note to everybody: if you use more than one repo and update via PackageKit, here is the cure: zypper rm PackageKit.
You have to lock it out, or it will be reinstalled.
Use zypper. Read carefully. Decide. Cancel is an option.
no, locking is not necessary on my Tumbleweed systems.
You really should mention something about why that is. Not everyone modifies their zypper config files. I fear shorties like this had a peripheral effect on getting yourself moderated. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
* Felix Miata
Patrick Shanahan composed on 2021-04-20 17:25 (UTC-0400):
* Carlos E.R. [04-20-21 16:56]:
Hans-Peter Jansen wrote:
A note to everybody: if you use more than one repo and update via PackageKit, here is the cure: zypper rm PackageKit.
You have to lock it out, or it will be reinstalled.
Use zypper. Read carefully. Decide. Cancel is an option.
no, locking is not necessary on my Tumbleweed systems.
You really should mention something about why that is. Not everyone modifies their zypper config files.
I do not recall modifying any zypper config except adding temporary locks to deal with such as current packman ffmpeg difficulties. and when packman catches up, I will remove those locks.
I fear shorties like this had a peripheral effect on getting yourself moderated.
if so, it very well may happen again. one need not live if fear. -- (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 freenode
On Tue, Apr 20, 2021 at 9:46 PM L A Walsh
On 2021/04/20 02:28, Carlos E.R. wrote:
On 20/04/2021 11.15, L A Walsh wrote:
I thought opensuse wasn't going to support a 32-bit release anymore?
Even if, often, when I'm looking through a batch of proposed solutions, I'll see: "nothing provides 'XXYZ', so we wanna remove about 20 x86_64 products and change architecture to i586 despite the inferior architecture".
Huh?... why would it not be able to use an x86_64 version of the same? ...
No, that's simply a side "misfeature" of the solver.
If there were no 32 bit versions, the solver will simply say there is no solution (as would happen with Leap). You basically have to interpret what it says and translate to "no solution".
Well, that's "sorta" what I thought, which is "sorta" what I wanted...since I don't have any of the 586 binaries pulled down, but the solver is only going by what is being offered in primary.xml.gz which has a bunch of i586 items.
Seems like from what Dominique is saying that I should only see those i586 packages when the equivalent x86_64 package isn't listed as even an option in the "primary.xml.gz" file, which, if I understand things, *SHOULD* be relatively rare?...
For some reason, there are 205 32bit packages installed on my Tumbleweed system. For example, why might I have both of these installed: libgraphite2-3-1.3.14-1.4.x86_64 libgraphite2-3-32bit-1.3.14-78.10.x86_64 What is a 32-bit x86_64 package? Surely it can only be one or the other. Unless the 64-bit package was compiled on a 32-bit platform. But is that relevant? It is the actual content that we are interested in (64 or 32 bit). But why both? If I try to delete these they all seem to be referencing each other. I can't seem to find the actual application that pulled them in. If I look at applications (not just libraries), I see that there is both wine and wine-32bit installed. As I only run 64-bit Windows apps in wine, would I need wine-32bit. It that is even the cause of the problem. No idea. Something seems confused. -- Roger Oberholtzer
On Wed, 2021-04-21 at 08:45 +0200, Roger Oberholtzer wrote:
For some reason, there are 205 32bit packages installed on my Tumbleweed system.
For example, why might I have both of these installed:
libgraphite2-3-1.3.14-1.4.x86_64 libgraphite2-3-32bit-1.3.14-78.10.x86_64
here, the -32bit package is indeed a 'rpm package' targetting 'arch = x86_64', but the binary inside is compiled on a i586 machine (is thus 32bit). This is mostly used for running 32bit applications on your 64bit OS. I for one am not using any such stuff, so I could remove everything up to glibc-32bit; but that also implies not using wine for example.
If I try to delete these they all seem to be referencing each other. I can't seem to find the actual application that pulled them in.
'wine' is the most commonly used app pulling in -32bit; and there is a pattern recommending 32bit stuff, to make sure users are not struggling with it (it is easier for the experienced one to get rid of them than the novice finding out that he needs them)
If I look at applications (not just libraries), I see that there is both wine and wine-32bit installed. As I only run 64-bit Windows apps in wine, would I need wine-32bit.
in theory, wine could probably work without wine-32bit, but the package has a hard dep. In the win world, 32bit apps are still a very common thing
It that is even the cause of the problem. No idea.
Not the same problem as Linda described. There, zypper wanted to replace .x86_64 packages with .i586 packages. Cheers, Dominique
On 4/21/21 8:45 AM, Roger Oberholtzer wrote:
What is a 32-bit x86_64 package? Surely it can only be one or the other. Unless the 64-bit package was compiled on a 32-bit platform. But is that relevant? It is the actual content that we are interested in (64 or 32 bit).
A 32-bit x86_64 package is a package for the x86_64 distribution architecture that contains 32-bit binaries intended for co-installation on 64-bit system. This is necessary because openSUSE does not allow co-installation of i586 packages on a 64-bit system unlike Debian or Ubuntu [1], for example. So if you need 32-bit versions of libraries on your 64-bit system in parallel, you will need to repackage the 32-bit libraries into x86_64 packages so that you can have a 32-bit and 64-bit libpng package installed, for example. On Debian and Ubuntu, I can just install the i386 package on an amd64 Debian/ Ubuntu system without having to repackage any 32-bit libraries into amd64 packages, meaning that all 32-bit library packages are automatically available for co-installation on Debian/Ubuntu. This also applies for co-installation of runtime libraries for ARM or PowerPC for cross-installation. On Debian/Ubuntu, I can just install the native armhf packages on my amd64 system while on openSUSE, I will have to put those armhf libraries into x86_64 packages so that they are installable on an x86_64 system. It's unfortunate that other distributions besides Debian/Ubuntu never adopted MultiArch. It's incredibly useful, especially when you are doing cross-builds.
But why both?
If you want to run 32-bit code on your 64-bit system, you need 32-bit runtime dependencies. Also, if you want to cross-compile for another architecture such as ARM, for example.
If I try to delete these they all seem to be referencing each other. I can't seem to find the actual application that pulled them in.
If I look at applications (not just libraries), I see that there is both wine and wine-32bit installed. As I only run 64-bit Windows apps in wine, would I need wine-32bit.
Well, the majority of all Windows applications available are still 32-bit (if you consider legacy applications that are no longer developed as well), so if you want to have maximum Wine compatibility, you need the 32-bit libraries as well. Adrian
On Wednesday 2021-04-21 09:10, John Paul Adrian Glaubitz wrote:
On 4/21/21 8:45 AM, Roger Oberholtzer wrote:
What is a 32-bit x86_64 package? Surely it can only be one or the other. Unless the 64-bit package was compiled on a 32-bit platform. But is that relevant? It is the actual content that we are interested in (64 or 32 bit).
A 32-bit x86_64 package is a package for the x86_64 distribution architecture that contains 32-bit binaries intended for co-installation on 64-bit system.
This is necessary because openSUSE does not allow co-installation of i586 packages on a 64-bit system unlike Debian or Ubuntu [1]
We allow it by way of rpm allowing it, but tools (and users) surrounding rpm do not necessarily expect to see a package present in multiple versions, let alone multiple architectures (which, for the remainder, is just treated as a version). However, let it be said that openSUSE _does_ use multiversioning, e.g. for kernel-*. Users expect `rpm -U` to upgrade a package, but that becomes a little ambiguous if there are multiple versions. There is a whole range of different ways users might interpret/intent "upgrade": 1. the way rpm does it: install argv[1] and delete all other versions across archs 2. the same but limit to current arch 3. install argv[1] and delete the oldest one copy, across, or limited to, one arch (something we want for kernels and currently do through extra scripts instead) 4. install argv[1] and delete the one most recent copy only, keeping whatever older versions there is/are. Across, or limited to, one arch. So there are at least 6 options, and with xxx-<specifier>.<arch>, we target option 2 (with a hack of the package name, yeah...)
On Wed, Apr 21, 2021 at 9:10 AM John Paul Adrian Glaubitz
Well, the majority of all Windows applications available are still 32-bit (if you consider legacy applications that are no longer developed as well), so if you want to have maximum Wine compatibility, you need the 32-bit libraries as well.
I did not mean to hijack the thread. I see that my 32bit rpm mystery is slightly different than the the original question. I just did not know that at the start... We develop both Linux (openSUSE) and Windows software. FYI, it's a high speed data collection system that is openSUSE based. (Not a sales blurb, but just to show some interesting things being done with openSUSE: https://rst.ramboll.com/matning/?sc_lang=en). Because of the fantastic availability in OBS of Windows builds of many packages, building on openSUSE our software for Windows works fantastic. It's all in the same Makefiles for all platforms. We only build 64-bit software. The only reason I have wine installed at all is that it is sometimes handy to verify a Windows build immediately. Wine allows this. I do not need the 32-bit version of wine. It would be nice if there was a direct way to remove it. -- Roger Oberholtzer
participants (12)
-
Carlos E. R. -
Carlos E.R. -
Dominique Leuenberger / DimStar -
Felix Miata -
Hans-Peter Jansen -
Jan Engelhardt -
John Paul Adrian Glaubitz -
Konstantin Voinov -
L A Walsh -
Patrick Shanahan -
Roger Oberholtzer -
Xu Zhao