Red Hat Bugzilla – Bug 1293050
file /etc/mono/config conflicts between attempted installs of mono-core-4.0.5-1.fc23.i686 and mono-core-4.0.5-1.fc23.x86_64
Last modified: 2017-08-08 08:34:40 EDT
My Fedora 23 can't receive updates with dnf AT ALL.
"dnf update" breaks on the error from the title.
Problem is, it tries to install two conflicting arch versions of mono for whatever reason.
YUM does NOT have this problem.
I'll attach output of both in a second.
This is actually pretty critical, as a "standard user's" Fedora can't receive any updates at all in such situation (this one was waiting for me to use yum before it could install 620 other updates).
Created attachment 1107767 [details]
dnf update mono\* output
Created attachment 1107768 [details]
yum-deprecated update mono\* output
We should investigate why depsolver wants to pull in mono-core.x86_64. Anyway these packages should not IMO conflicts with each other. Fedora support multiple architecture installation.
Neither of us has actual need to have two arch versions of Mono installed in parallel, so why would we demand this from Mono maintainers?
At the same time, yum never did this on upgrades, so it's probably dnf/libresolv regression (OR a yum bug that mono depended on for years :)). Either way, it can break upgrades (as it did for that machine) and should be taken very seriously.
Now "fedup download" refuses to work...
Install 103 Packages
Upgrade 2802 Packages
Remove 5 Packages
Downgrade 10 Packages
Total size: 3.2 G
Is this ok [y/N]: y
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
file /etc/mono/config conflicts between attempted installs of mono-core-4.2.4-1.fc24.i686 and mono-core-4.2.4-1.fc24.x86_64
AGAIN, no problem with:
yum-deprecated --releasever=24 update mono-core
And this time situation is worse because Fedora 24's marketing praised the new purely graphical method to upgrade the system. Guess how the target audience of that tool will deal with this situation (install Ubuntu).
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
It is definitely bug in mono, not in DNF.
@Leszek: how can I reproduce this situation?
Somehow I need the 32 bit version of mono-core, and the rest all from 64 bit.
dnf install mono-core-4.0.4-1.fc23.i686
does not work, it wants to install both the i686 and x86_64 version, and shows similar errors as you describe during the upgrade.
yum-deprecated install mono-core-4.0.4-1.fc23.i686
also does not work, Error: Multilib version problems found
so the question is, how did you get to that situation?
I wonder if you have upgraded from Fedora 22, with the ancient Mono installed?
Would this work, to completely remove mono, and then install it fresh again?
If there is a reproducible test case, I can try to fix it. But otherwise I have no idea.
That system has been upgraded to every release since F19, but you don't need to upgrade anything, or even use anything other than dnf to reproduce.
Steps to reproduce on clean F23:
dnf install mono-core.i686 (will install only i686 mono-core, MAGIC)
(OPTIONAL) dnf downgrade mono-core (just see what it tries to do!)
dnf downgrade mono-\* (MORE MAGIC)
dnf update (this breaks)
dnf still happily installs i686 mono, even though it will then be impossible to upgrade. This is what this bug is about.
The optional step is probably one more manifestation of the same issue - you ask it to downgrade one package, but instead, this also tries to install x86_64 build, and in a new version :)
Then there's the "more magic" step which actually works correctly (doesn't try to bring in the x86-64 version).
Whatever problems the mono packaging might have, there certainly IS an issue with dnf - the resolver behaves differently when installing, differently when downgrading, and differently when upgrading a package. Yum, on the other hand, is consistent, it can upgrade what it allowed to be installed :)
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.