| Summary: | Let "dnf builddep" and "dnf upgrade" automatically find the 64bit requires on 64bit systems, it now pulls in a lot of 32bit packages | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Marja Van Waes <marja11> |
| Component: | RPM Packages | Assignee: | Neal Gompa <ngompa13> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Normal | CC: | rverschelde |
| Version: | Cauldron | Keywords: | UPSTREAM |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.redhat.com/show_bug.cgi?id=1332830 | ||
| Whiteboard: | |||
| Source RPM: | dnf-1.1.8-2.mga6 | CVE: | |
| Status comment: | |||
| Attachments: |
dnfupdates/201605122139
dnfupdates/201605142101 |
||
|
Description
Marja Van Waes
2016-05-03 19:26:12 CEST
Marja Van Waes
2016-05-03 19:26:26 CEST
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) =>
UPSTREAM 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 =>
RESOLVED |