I've split this out from bug 31989 having stumbled on it there, as it seems a major issue in its own right. Description of problem: wine32 won't install after system package updates To demonstrate problem: 1. install fresh M9. 2. on reboot, enable a mirror and enable core 32-bit repositories. 3. install wine32. Pulls ine wine64 and other dependencies: works fine. 4. delete wine32 5. MCC -> update your system. At this instant it finds 452 packages to update. Proceed. 6. Update stalls with some package conflicts - not a big issue as a reboot and re-update will fix it, but provides a handy bisect for the updates. See attached file installprob.txt 7. At this partially updated point (170 packages still to update), can install wine32 OK. Do this, then delete it. 8. Reboot, finish the update of the 170 remaining packages, listed in attached file late-updates txt (9. I note in passing the conflicting packages needing to be removed during this remaining-updates process, listed in attached file upgrade_conflicting_packages.txt. Probably not useful, but...) 10. Attempt wine32 install via MCC: fails silently. 11. Attempt wine32 install via urpmi. Fails with msg: The following packages can't be installed because they depend on packages that are older than the installed ones: See attached file urpmi_fail.txt for involved files.
Created attachment 14217 [details] see initial bug report text
Created attachment 14218 [details] see initial bug report text
Created attachment 14219 [details] see initial bug report text
Created attachment 14220 [details] see initial bug report text
Ok, got those files attached. I'm mildly surprised (perhaps through ignorance) at this issue appearing. I'd generally assumed that packages like wine32 would re-compile andor run 'as-is' happily against later versions of their dependencies so this is unexpected? (or hasn't this happened yet and still to be done??? Apologies to our over-busy package maintainers if my ignorance is showing..) Regards to all, Tony
While I'm here, just got Aurelian'c comment in bug 31989 reproduced here: > The following packages can't be installed because they depend on packages > that are older than the installed ones: Most likely the corresponding 32bit repos to the already available 64bit ones are not enabled, i.e. repo "Core Updates", a 64bit repo, is enabled while repo "Core 32bit Updates" is not, similar to bug #29205. I'd not havfe thought of that, but at least for Core 32-bit updates the suggestion doesn't seem to be the issue, in that all newly installed M9 and earlier versions have Core 32-bit updates ticked/installed by default although core 32 bit Release is not ticked/enabled by default. I tried adding a tick in the Enabled box for Core 32bit updates as well as in the Updates box but that didn't help.
As root, could you run in a terminal twice "urpmi --auto-update --auto --test" and post the output of the second run? It would just list and update the database on all your active repos and list all available updates for your system with no actual update/action performed. The output from the second run will be cleaner for posting.
CC: (none) => arusanu
Created attachment 14221 [details] output of urpmi --auto-update --auto --test added result of uprmi run in attachment named accordingly
I note also the symchronous comment from Jose Alberto Valle Cid in qa: Did you have updates repositories for 32bit repositories? provide output of urpmq --list-media active Result below: ]# urpmq --list-media active Core Release (distrib1) Core Updates (distrib3) Core Backports (distrib7) Nonfree Release (distrib11) Nonfree Updates (distrib13) Tainted Release (distrib21) Core 32bit Release (distrib31) Core 32bit Updates (distrib32) Tony
(In reply to Tony Blackwell from comment #9) > I note also the symchronous comment from Jose Alberto Valle Cid in qa: > > Did you have updates repositories for 32bit repositories? > provide output of > > urpmq --list-media active > > Result below: > ]# urpmq --list-media active > Core Release (distrib1) > Core Updates (distrib3) > Core Backports (distrib7) > Nonfree Release (distrib11) > Nonfree Updates (distrib13) > Tainted Release (distrib21) > Core 32bit Release (distrib31) > Core 32bit Updates (distrib32) > > > Tony As I guess you don't have all the needed repositories https://wiki.mageia.org/en/Mageia_9_Release_Notes#32-bit_repositories_on_64-bit_systems urpmq --list-media active Core Release Core Updates Nonfree Release Nonfree Updates Tainted Release Tainted Updates Core 32bit Release Core 32bit Updates Nonfree 32bit Release Nonfree 32bit Updates Tainted 32bit Release Tainted 32bit Updates Please take care of eneble repositories in pairs Release and Updates
While I'm not quite clear why you had to remove/reinstall wine32 so often and I cannot reproduce your issues with your listed media, one other thing to try is to clear your urpmi cache(urpmi --clean), uninstall wine64(urpme wine64) and try to reinstall wine64 which should pull 32bit pkgs if 32bit repos are enabled. Unfortunately, at this moment, we cannot use "urpme --auto-orphans" to clean up all wine dependencies, see bug #31699. Also, if you at some point turned on any other media and switch it back off then you may have some conflicting packages in your system, so the next step is to enable all your 64/32bit repos that you have used in pairs, as katnatek mentioned in comment #10, and try again to reinstall wine.
Fixed! (FYI, all my wine32 installs and removals was just to debug were in seting up new M9 the install failed.) OK, so: 1. enabled matching pairs of repositories; e.g. I didn't have the pair of Tainted 32-bit or any nonfree 32bit. 2. ran urpmi --clean 3. uninstalled wine64 4. reinstalled wine64 5. uneventfully installed wine32. Thankyou Aurelian, Katnatek and Jose (must learn to type e acute - sorry!) Very prompt assistance from you all Truly appreciated Tony (I've marked this resolved/fixed - tell me if someone else should have done this).
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
(In reply to Tony Blackwell from comment #12) > Fixed! > > (FYI, all my wine32 installs and removals was just to debug were in seting > up new M9 the install failed.) > > OK, so: > 1. enabled matching pairs of repositories; e.g. I didn't have the pair of > Tainted 32-bit or any nonfree 32bit. > 2. ran urpmi --clean > 3. uninstalled wine64 > 4. reinstalled wine64 > 5. uneventfully installed wine32. > > Thankyou Aurelian, Katnatek and Jose (must learn to type e acute - sorry!) One more of needed, I'm José Alberto from QA list, katnatek is my nick ;)
I believe there was nothing fixed in Mageia. We have a bunch of open bugs for wine listed in errata already.
Resolution: FIXED => INVALIDCC: (none) => fri