It would be nice if, in a 64bit environment, "dnf builddep" would not pull in 32bit packages to solve Build Requires when they can or should be solved with 64bit packages. "urpmi --buildrequires" handles this automatically Son_Goku told me that it can be worked around by adding "--exclude *.i586" to the command. That works very well, but it is easily forgotten or mis-typed (tab doesn't work for --exclude).
CC: (none) => rverschelde
The issue is caused by DNF processing by literal package names first and stopping after it finds a match (from the 32-bit repositories). I've filed a request upstream to make it possible to process Capabilities (such as Provides) before using the literal package name as a decider. That bug is linked in "See Also".
Keywords: (none) => UPSTREAMSee Also: (none) => https://bugzilla.redhat.com/show_bug.cgi?id=1332830
Just for the record (I should maybe put this in the wiki): I've started using LANGUAGE=C dnf upgrade -v --refresh --exclude *.i586 instead of that command without "--exclude *.i586" because even while packages like lib64xcb-dri2_0-1.11.1-2.mga6 lib64xcb-dri3_0-1.11.1-2.mga6 lib64xcb-glx0-1.11.1-2.mga6 were already installed, dnf upgrade wanted to install the 32 bit versions, like libxcb-dri2_0 i586 1.11.1-2.mga6 mageia-cauldron-core-i586 13 k libxcb-dri3_0 i586 1.11.1-2.mga6 mageia-cauldron-core-i586 11 k libxcb-glx0 i586 1.11.1-2.mga6 mageia-cauldron-core-i586 26 k
I'm not completely certain what's going on here, actually. Could you please re-run this (where it installs 32-bit libraries with the upgrade) with --debugsolver? It should create a directory called "debugdata" in your current directory. Archive it and attach it to this ticket.
(In reply to Neal Gompa from comment #3) > I'm not completely certain what's going on here, actually. > > Could you please re-run this (where it installs 32-bit libraries with the > upgrade) with --debugsolver? It should create a directory called "debugdata" > in your current directory. Archive it and attach it to this ticket. Will do when it happens again.
Created attachment 7796 [details] dnfupdates/201605122139 Since the debugsolver output is not yet available, attaching the cli output of first time I saw 32bit packages were going to be installed
Created attachment 7797 [details] dnfupdates/201605142101 and of the 2nd time
I've managed to reproduce the test case from a freshly installed Mageia 6 dev1 VM where I installed DNF and configured it, and then ran "dnf upgrade". I've provided two debugsolver data sets, one with both 32-bit and 64-bit repositories enabled, and one with just 64-bit repositories enabled. Since the tarball is too big to be attached, I've uploaded debugsolver data for this issue to http://kinginuyasha.enanocms.org/downloads/mgabug18343-debugdata.tar.xz
I've also managed to reproduce the test case of the original issue with builddep. I've provided four debugsolver data sets, two with both 32-bit and 64-bit repositories enabled, and two with just 64-bit repositories enabled. One of each kind has "--best --allowerasing" enabled, and the other set does not. Since the tarball is too big to be attached, I've uploaded debugsolver data for this issue to http://kinginuyasha.enanocms.org/downloads/mgabug18343-builddep-debugdata.tar.xz
Note this issue cropped up with qemu-2.6.0-3.mga6.src.rpm.
I haven't tested this in dnf2, yet, is there a chance this got fixed?
Summary: Let "dnf builddep" automatically find the 64bit requires on 64bit systems, it now pulls in a lot of 32bit packages => Let "dnf builddep" and "dnf upgrade" automatically find the 64bit requires on 64bit systems, it now pulls in a lot of 32bit packages
There is a chance this is fixed in dnf-2.0, as there was a PR related to the rhbz counterpart to this bug that was merged into dnf in September.
(In reply to Neal Gompa from comment #11) > There is a chance this is fixed in dnf-2.0, as there was a PR related to the > rhbz counterpart to this bug that was merged into dnf in September. I just tried with dnf-2.0.0-0.0.1.rc1.mga6 to install the builddeps of lokalize, It works great now, it selects 3 missing noarch BRs from the i586 repository, which is fine, and everything else (90 packages, almost all libraries) from x86_64, exactly as it should :-D
(In reply to Marja van Waes from comment #12) > It works great now, it selects 3 missing noarch BRs from the i586 > repository, which is fine, and everything else (90 packages, almost all > libraries) from x86_64, exactly as it should :-D Is it really fine? To me noarch packages should still be taken from the x86_64 repository. I think that's whay urpmi does, doesn't it?
(In reply to Samuel Verschelde from comment #13) > (In reply to Marja van Waes from comment #12) > > It works great now, it selects 3 missing noarch BRs from the i586 > > repository, which is fine, and everything else (90 packages, almost all > > libraries) from x86_64, exactly as it should :-D > > Is it really fine? To me noarch packages should still be taken from the > x86_64 repository. I think that's whay urpmi does, doesn't it? It shouldn't matter in this case. In an ideal state, we would have x86_64, i586, and noarch split into their own repositories. But since it is noarch, it doesn't matter where it comes from.
(In reply to Neal Gompa from comment #14) > (In reply to Samuel Verschelde from comment #13) > > (In reply to Marja van Waes from comment #12) > > > It works great now, it selects 3 missing noarch BRs from the i586 > > > repository, which is fine, and everything else (90 packages, almost all > > > libraries) from x86_64, exactly as it should :-D > > > > Is it really fine? To me noarch packages should still be taken from the > > x86_64 repository. I think that's whay urpmi does, doesn't it? > > It shouldn't matter in this case. In an ideal state, we would have x86_64, > i586, and noarch split into their own repositories. But since it is noarch, > it doesn't matter where it comes from. Yet it doesn't feel right that the x86_64 is not preferred :) But I'm not able to say if there's a case in which it could cause an issue.
(In reply to Samuel Verschelde from comment #15) > (In reply to Neal Gompa from comment #14) > > > > It shouldn't matter in this case. In an ideal state, we would have x86_64, > > i586, and noarch split into their own repositories. But since it is noarch, > > it doesn't matter where it comes from. > > Yet it doesn't feel right that the x86_64 is not preferred :) > > But I'm not able to say if there's a case in which it could cause an issue. When the i586 repo is excluded, or not available, noarch packages get pulled from x86_64 in such cases. I can't imagine any issue.
@Marja, Is this still an issue with DNF 2.0 in Cauldron now? This should be fixed now.
(In reply to Neal Gompa from comment #17) > @Marja, > > Is this still an issue with DNF 2.0 in Cauldron now? This should be fixed > now. I forgot to close this report when DNF 2.0 was pushed to the Mageia repositories. Thanks, Neal :-)
Status: NEW => RESOLVEDResolution: (none) => FIXED