Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1320755
| Summary: | dnf dependency resolution seriously broken in a presence of packages for an additionnal arch | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal.jnn> | ||||||||||||||||||||
| Component: | dnf | Assignee: | Jaroslav Mracek <jmracek> | ||||||||||||||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||
| Version: | rawhide | CC: | jmracek, jsilhan, mluscon, packaging-team-maint, pnemade, rdieter, ttomasz, vmukhame | ||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||
| Last Closed: | 2016-05-18 13:59:33 UTC | Type: | Bug | ||||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||
| Embargoed: | |||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
Created attachment 1139780 [details]
a list of packages for the same transaction with "--exclude='*.i686' added
With today updates 'dnf update' still attempts to install the same 134 spurious packages as before. I do know if this is related but when "--exclude='*.i686'" is used the the following complaint shows up: /usr/lib64/python3.5/re.py:203: FutureWarning: split() requires a non-empty pattern match. return _compile(pattern, flags).split(string, maxsplit) Pleas rerun your commands with a --debugsolver option and attach created debugdata. (In reply to Michal Luscon from comment #3) > Pleas rerun your commands with a --debugsolver option and attach created debugdata. Do you need rawhide.repo.gz and @System.repo.gz? This is coming close to 8 MB and I am not sure if bugzilla even will accept an attachment of that size. Created attachment 1142359 [details]
--debugsolver data from a dnf run
(Apparently a file of this size is still acceptable to bugzilla)
The attached archive contains the following files:
debugdata.exclude/@System.repo.gz
debugdata.exclude/rawhide.repo.gz
debugdata.exclude/testcase.t
debugdata.exclude/solver.result
debugdata.noexcl/@System.repo.gz
debugdata.noexcl/rawhide.repo.gz
debugdata.noexcl/testcase.t
debugdata.noexcl/solver.result
Those in debugdata.noexcl are from 'dnf -b --debugsolver update' run; the other directory contains data produced by 'dnf -b --debugsolver --exclude="*.i686" update'. @System.repo.gz and rawhide.repo.gz are hardlinked as they do not differ in both cases. Without an explicit --exclude=... dnf attempts to install the same 134 spurious packages as before.
I just ran into similar issue while updating F24 x86_64 (alpha) in VM. The F24 was already updated once.
I noticed too late that the update pulled in 134 additional .i686 packages, so I cannot generate a debug log for the update.
But interestingly it was enough to issue two dnf remove commands to remove all of them. I am attaching the debug files for the remove runs.
dnf remove --debugsolver zlib.i686
# removed 131 packages
solver.1.result
@System.repo.1.gz
testcase.1.t
dnf remove --debugsolver glibc.i686
# removed the remaining 3 packages
glibc.i686
nss-softokn-freebl.i686
xorg-x11-drv-geode.i686
solver.2.result
@System.repo.2.gz
testcase.2.t
Hope it helps.
Created attachment 1142858 [details]
solver.1.result
dnf remove --debugsolver zlib.i686
Created attachment 1142859 [details]
@System.repo.1.gz
dnf remove --debugsolver zlib.i686
Created attachment 1142860 [details]
testcase.1.t
dnf remove --debugsolver zlib.i686
Created attachment 1142861 [details]
solver.2.result
dnf remove --debugsolver glibc.i686
Created attachment 1142862 [details]
@System.repo.2.gz
dnf remove --debugsolver glibc.i686
Created attachment 1142863 [details]
testcase.2.t
dnf remove --debugsolver glibc.i686
thanks for the data. Looks like another variant of bug #1325471 *** This bug has been marked as a duplicate of bug 1325471 *** |
Created attachment 1139778 [details] list of packages dnf attempts to install with a plain "update" Description of problem: My rawhide test installation on x86_64 is "32-bit clean" on purpose. Still after running on it 'dnf -v -b update' dnf attempts to install on it 134 definitely unwanted i686 packages. The whole list of an attempted transaction attached. After an explicit 'dnf -v -b --exclude='*.i686 update' dnf was just happy to drop from a transaction only those 32-bit packages and run without any fuss. Moreover after this was completed the subsequent try of 'dnf -v -b update' comes back with "Nothing to do". It is really hard to asses why this may be happening as dnf is really stingy with an information about what it is really doing. Version-Release number of selected component (if applicable): dnf-1.1.7-2.fc25.noarch How reproducible: I have seen that before but not consistently. Expected results: dnf not attempting to install something which was not asked for - explicitely or implicitely. Additional info: That particular installation does not have any 32-bit packages so it is comparatively easy to guard against such impositions as above but in "production", where some i686 packages may be needed, such "--exclude='*.i686 update'" could not be used and protecting an installation from an extra junk will be hard.