Description of problem: Latest wine depends on mingw{32,64}-libtiff, which in turn depends on mingw{32,64}(libstdc++-6.dll). That is provided by mingw{32,64}-gcc-c++ and not split out like native libstdc++ package. Version-Release number of selected component (if applicable): mingw64-gcc-12.2.1-5.fc37 How reproducible: Always Steps to Reproduce: 1. dnf install mingw{32,64}-libtiff Actual results: Excessive dependencies are getting installed, i.e. development packages: isl mingw32-binutils mingw32-binutils-generic mingw32-cpp mingw32-gcc mingw32-gcc-c++ mingw32-headers mingw32-libjpeg-turbo mingw32-winpthreads-static Expected results: Only mingw{32,64}-libstdc++ get installed apart from mingw{32,64}-libtiff. Additional info: See bug 2078226 for similar issue that resulted in libgcc being split out.
FWIW, this split will cut the runtime dependency tree of nearly 400 packages: $ dnf repoquery --whatrequires 'mingw32(libstdc++-6.dll)'|wc -l 196 $ dnf repoquery --whatrequires 'mingw64(libstdc++-6.dll)'|wc -l 193
Something like this? https://koji.fedoraproject.org/koji/taskinfo?taskID=99083294
Yes, this works well: ============================================================================================================================================ Package Architecture Version Repository Size ============================================================================================================================================ Installing: mingw64-libstdc++ x86_64 13.0.1-2.fc39 @commandline 5.7 M mingw64-libtiff noarch 4.4.0-2.fc38 fedora 318 k Installing dependencies: mingw-binutils-generic x86_64 2.40-1.fc39 fedora 982 k mingw-filesystem-base noarch 145-2.fc38 fedora 24 k mingw64-crt noarch 10.0.0-4.fc38 fedora 2.9 M mingw64-filesystem noarch 145-2.fc38 fedora 137 k mingw64-libgcc x86_64 13.0.1-1.fc39 fedora 251 k mingw64-libjpeg-turbo noarch 2.1.4-2.fc38 fedora 266 k mingw64-winpthreads noarch 10.0.0-3.fc38 fedora 49 k mingw64-zlib noarch 1.2.13-2.fc38 fedora 100 k Transaction Summary ============================================================================================================================================ Install 10 Packages Any idea why mingw64-filesystem requires binutils? # rpm -e mingw-binutils-generic error: Failed dependencies: mingw-binutils-generic is needed by (installed) mingw64-filesystem-145-2.fc38.noarch
It is because mingw-filesystem ships the macros.mingwXX which call mingw-objdump & co. which are part of mingw-binutils-generic. I've submitted the builds for mingw-gcc-13.0.1-2.fc39, mingw-gcc-12.2.1-8.fc38 and mingw-gcc-12.2.1-6.fc37 with the split out libstdc++.
FEDORA-2023-ebe5039088 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ebe5039088
FEDORA-2023-f5fcbb26b3 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f5fcbb26b3
FEDORA-2023-ebe5039088 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ebe5039088` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ebe5039088 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-f5fcbb26b3 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f5fcbb26b3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The split package looks great, but I think it warrants a notification to the devel@ mailing list, because it might require adding explicit build dependencies to mingw (sub)packages. For example, my gstreamermm package stopped building and I had to add the missing BuildRequires: mingw{32,64}-gcc-c++. Admittedly, they should've been there in the first place and this change just exposed the omission. :)
FEDORA-2023-ebe5039088 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-f5fcbb26b3 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.