Description of problem: I'm trying to upgrade from mono-devel-6.6.0-5.fc32.i686 to mono-devel-6.6.0-7.fc32.i686.rpm. It fails with a conflict on /usr/bin/mono-find-provides Version-Release number of selected component (if applicable): mono-devel-6.6.0-7.fc32.i686.rpm How reproducible: Always Steps to Reproduce: 1. previously: yum install mono-core.x86_64 mono-devel.i686 2. now: yum update mono-devel.i686 Actual results: Fedora 32 - x86_64 - Updates 23 kB/s | 14 kB 00:00 Fedora 32 - x86_64 - Updates 127 kB/s | 448 kB 00:03 Fedora 32 - local packages for x86_64 164 kB/s | 3.0 kB 00:00 Dependencies resolved. ==================================================================================================================================== Package Architecture Version Repository Size ==================================================================================================================================== Upgrading: mono-core i686 6.6.0-7.fc32 updates 17 M mono-core x86_64 6.6.0-7.fc32 updates 17 M mono-data x86_64 6.6.0-7.fc32 updates 4.8 M mono-data-sqlite x86_64 6.6.0-7.fc32 updates 79 k mono-devel i686 6.6.0-7.fc32 updates 6.0 M mono-extras x86_64 6.6.0-7.fc32 updates 491 k mono-mvc x86_64 6.6.0-7.fc32 updates 483 k mono-wcf x86_64 6.6.0-7.fc32 updates 969 k mono-web x86_64 6.6.0-7.fc32 updates 2.6 M mono-winforms x86_64 6.6.0-7.fc32 updates 1.7 M monodoc x86_64 6.6.0-7.fc32 updates 19 M Installing dependencies: mono-devel x86_64 6.6.0-7.fc32 updates 5.9 M Transaction Summary ==================================================================================================================================== Install 1 Package Upgrade 11 Packages Total download size: 75 M Is this ok [y/N]: y Downloading Packages: (1/12): mono-devel-6.6.0-7.fc32.x86_64.rpm 237 kB/s | 5.9 MB 00:25 (2/12): mono-data-6.6.0-7.fc32.x86_64.rpm 214 kB/s | 4.8 MB 00:22 (3/12): mono-data-sqlite-6.6.0-7.fc32.x86_64.rpm 145 kB/s | 79 kB 00:00 (4/12): mono-devel-6.6.0-7.fc32.i686.rpm 224 kB/s | 6.0 MB 00:27 (5/12): mono-core-6.6.0-7.fc32.x86_64.rpm 227 kB/s | 17 MB 01:16 (6/12): mono-extras-6.6.0-7.fc32.x86_64.rpm 220 kB/s | 491 kB 00:02 (7/12): mono-mvc-6.6.0-7.fc32.x86_64.rpm 209 kB/s | 483 kB 00:02 (8/12): mono-core-6.6.0-7.fc32.i686.rpm 216 kB/s | 17 MB 01:20 (9/12): mono-wcf-6.6.0-7.fc32.x86_64.rpm 243 kB/s | 969 kB 00:03 (10/12): mono-winforms-6.6.0-7.fc32.x86_64.rpm 242 kB/s | 1.7 MB 00:07 (11/12): mono-web-6.6.0-7.fc32.x86_64.rpm 244 kB/s | 2.6 MB 00:10 (12/12): monodoc-6.6.0-7.fc32.x86_64.rpm 336 kB/s | 19 MB 00:56 ------------------------------------------------------------------------------------------------------------------------------------ Total 555 kB/s | 75 MB 02:19 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 'yum clean packages'. Error: Transaction test error: file /usr/bin/mono-find-provides conflicts between attempted installs of mono-devel-6.6.0-7.fc32.i686 and mono-devel-6.6.0-7.fc32. x86_64 file /usr/bin/mono-find-requires conflicts between attempted installs of mono-devel-6.6.0-7.fc32.i686 and mono-devel-6.6.0-7.fc32. x86_64 file /usr/share/mono-2.0/mono/eglib/eglib-config.h conflicts between attempted installs of mono-devel-6.6.0-7.fc32.i686 and mono-d evel-6.6.0-7.fc32.x86_64 Expected results: Upgrade succeeds Additional info:
I can reproduce this in a Fedora 32 64-bit container: dnf install mono-devel-6.6.0-5.fc32.i686 This will install some mono 64 bit packages, but not mono-devel dnf update This will try to install mono-devel, and that fails. I have no idea, why mono-devel 64 bit is now required. I have no idea, why the 64 bit packages are installed when 32 bit packages are installed. I don't really know why you need 32 bit packages on a 64 bit machine?
I need the 32-bit package to run 3rd party 32-bit software.
There is actually a difference in those files, so at the moment, we cannot install mono-devel.i686 and mono-devel.x86_64 at the same time. You can only install both packages at the same time, if the files are identical. [root@l183-f32 tmp]# diff -uNr 32bit/usr/bin/mono-find-requires 64bit/usr/bin/mono-find-requires --- 32bit/usr/bin/mono-find-requires 2020-06-20 07:10:16.000000000 +0200 +++ 64bit/usr/bin/mono-find-requires 2020-06-20 07:04:31.000000000 +0200 @@ -26,7 +26,7 @@ # Can override .config scanning if specified : ${IGNORE_CONFIG_SCAN=0} -libdir=$prefix/lib +libdir=$prefix/lib64 bindir=$prefix/bin # Bail out if monodis or libmono is missing @@ -36,7 +36,7 @@ fi # special case for 64bit archs -if test "xlib" = "xlib64" ; then +if test "xlib64" = "xlib64" ; then libext="()(64bit)" else # (note, this works on ppc64 since we only have 32bit mono) [root@l183-f32 tmp]# diff -uNr 32bit/usr/bin/mono-find-provides 64bit/usr/bin/mono-find-provides --- 32bit/usr/bin/mono-find-provides 2020-06-20 07:10:16.000000000 +0200 +++ 64bit/usr/bin/mono-find-provides 2020-06-20 07:04:31.000000000 +0200 @@ -23,7 +23,7 @@ # Set the prefix, unless it is overriden (used when building mono rpms) : ${prefix=/usr} -libdir=$prefix/lib +libdir=$prefix/lib64 bindir=$prefix/bin # Bail out if monodis or libmono is missing [root@l183-f32 tmp]# diff -uNr 32bit/usr/share/mono-2.0/mono/eglib/eglib-config.h 64bit/usr/share/mono-2.0/mono/eglib/eglib-config.h --- 32bit/usr/share/mono-2.0/mono/eglib/eglib-config.h 2020-06-20 07:08:46.000000000 +0200 +++ 64bit/usr/share/mono-2.0/mono/eglib/eglib-config.h 2020-06-20 07:03:26.000000000 +0200 @@ -26,7 +26,7 @@ typedef size_t gsize; typedef ptrdiff_t gssize; -#define G_GSIZE_FORMAT "u" +#define G_GSIZE_FORMAT "lu" #if defined (HOST_WATCHOS) #undef G_BREAKPOINT We could make the files /usr/bin/mono-find-provides and /usr/bin/mono-find-requires the same, and check for existance of directory $prefix/lib64. But I don't know about eglib-config.h, how to keep that file the same for both arches? The other option would be, to prevent installing mono-core.x86_64 when installing mono-devel.i686. But I don't know how to do that. A workaround seems to be: dnf remove mono-core dnf install mono-core.i686 dnf install mono-devel.i686 # there is no mono-core.x86_64 installed That seems to work for me on my test system. This also does seem to work: dnf remove mono-core dnf install mono-devel.i686 # installs mono-core.i686 and mono-core.x86_64 I am open to any suggestions for a proper solution...
Another clue: # yum update mono-devel.i686 --exclude=mono-devel.x86_64 Fedora 32 - local packages for x86_64 402 kB/s | 3.0 kB 00:00 Dependencies resolved. Problem: mono-devel-6.6.0-7.fc32.i686 has inferior architecture - cannot install the best update candidate for package mono-devel-6.6.0-5.fc32.i686 - package mono-devel-6.6.0-7.fc32.x86_64 is filtered out by exclude filtering Nothing to do. Complete!
I think this is bug in DNF's multilib handling, since I see nothing obiously wrong with mono.spec. To reproduce: podman run -it fedora:32 bash [root@18e528d26668 /]# dnf -y --disablerepo=updates install mono-devel.i686 … [success] [root@18e528d26668 /]# dnf -y update mono-devel.i686 Last metadata expiration check: 0:00:29 ago on Sat Aug 22 14:50:04 2020. Dependencies resolved. ==================================================================================================================================== Package Architecture Version Repository Size ==================================================================================================================================== Upgrading: mono-core i686 6.6.0-7.fc32 updates 17 M mono-core x86_64 6.6.0-7.fc32 updates 17 M mono-data x86_64 6.6.0-7.fc32 updates 4.8 M mono-data-sqlite x86_64 6.6.0-7.fc32 updates 79 k mono-devel i686 6.6.0-7.fc32 updates 6.0 M mono-extras x86_64 6.6.0-7.fc32 updates 491 k mono-mvc x86_64 6.6.0-7.fc32 updates 483 k mono-wcf x86_64 6.6.0-7.fc32 updates 969 k mono-web x86_64 6.6.0-7.fc32 updates 2.6 M mono-winforms x86_64 6.6.0-7.fc32 updates 1.7 M monodoc x86_64 6.6.0-7.fc32 updates 19 M Installing dependencies: mono-devel x86_64 6.6.0-7.fc32 updates 5.9 M Transaction Summary ==================================================================================================================================== Install 1 Package Upgrade 11 Packages Total download size: 75 M Downloading Packages: (1/12): mono-devel-6.6.0-7.fc32.x86_64.rpm 148 kB/s | 5.9 MB 00:40 (2/12): mono-core-6.6.0-7.fc32.x86_64.rpm 330 kB/s | 17 MB 00:52 (3/12): mono-data-sqlite-6.6.0-7.fc32.x86_64.rpm 206 kB/s | 79 kB 00:00 (4/12): mono-data-6.6.0-7.fc32.x86_64.rpm 193 kB/s | 4.8 MB 00:25 (5/12): mono-extras-6.6.0-7.fc32.x86_64.rpm 204 kB/s | 491 kB 00:02 (6/12): mono-mvc-6.6.0-7.fc32.x86_64.rpm 182 kB/s | 483 kB 00:02 (7/12): mono-devel-6.6.0-7.fc32.i686.rpm 274 kB/s | 6.0 MB 00:22 (8/12): mono-wcf-6.6.0-7.fc32.x86_64.rpm 164 kB/s | 969 kB 00:05 (9/12): mono-core-6.6.0-7.fc32.i686.rpm 225 kB/s | 17 MB 01:17 (10/12): mono-web-6.6.0-7.fc32.x86_64.rpm 242 kB/s | 2.6 MB 00:10 (11/12): mono-winforms-6.6.0-7.fc32.x86_64.rpm 164 kB/s | 1.7 MB 00:10 (12/12): monodoc-6.6.0-7.fc32.x86_64.rpm 540 kB/s | 19 MB 00:35 ------------------------------------------------------------------------------------------------------------------------------------ Total 682 kB/s | 75 MB 01:53 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 test error: file /usr/bin/mono-find-provides conflicts between attempted installs of mono-devel-6.6.0-7.fc32.i686 and mono-devel-6.6.0-7.fc32.x86_64 file /usr/bin/mono-find-requires conflicts between attempted installs of mono-devel-6.6.0-7.fc32.i686 and mono-devel-6.6.0-7.fc32.x86_64 file /usr/share/mono-2.0/mono/eglib/eglib-config.h conflicts between attempted installs of mono-devel-6.6.0-7.fc32.i686 and mono-devel-6.6.0-7.fc32.x86_64 [root@18e528d26668 /]# dnf -y remove mono-devel.i686 … [success] [root@18e528d26668 /]# dnf -y install mono-devel.i686 … [success—installs all the packages I wanted updated] In my opinion, dnf update should have the same result as remove/install. I suggest the mono maintainers reassign to dnf.
The root cause is that the packages contain a file under the same path but with different content/checksums. RPM errors out in such cases. This has to be fixed in the packages.
Daniel: Thank you! You were right. I modified Mono in Rawhide, to have identical files for both architectures. Now I am able to upgrade from Mono 6.10.0-0 to 6.10.0-1 on Rawhide, and mono-core-6.10.0-1.fc34.x86_64 and mono-core-6.10.0-1.fc34.i686 are installed, but only mono-devel-6.10.0-1.fc34.i686 is installed. I don't get any errors anymore. I will backport this to F33 and F32.
FEDORA-2020-d7f9fbd8e0 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-d7f9fbd8e0
FEDORA-2020-733020691d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-733020691d
FEDORA-2020-733020691d has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-733020691d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-733020691d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-d7f9fbd8e0 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d7f9fbd8e0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d7f9fbd8e0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-d7f9fbd8e0 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-733020691d has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.