Description of problem: ghc9.4-base package provides libffi.so.8()(64bit) virtual package, so in can be installed instead of proper libffi as a dependency of many packages, including low-level system packages. That can break the whole operating system, including DNF and other basic system utilities. Version-Release number of selected component (if applicable): ghc9.4-9.4.0.20220501-1.fc37 Reproducible in Koji build - they fail to load libffi.so.8 ImportError: libffi.so.8: cannot open shared object file: No such file or directory Example: https://koji.fedoraproject.org/koji/taskinfo?taskID=86776860 Corresponding Koschei build: https://koschei.fedoraproject.org/build/12813323 Also reproducible in MBI CI: https://mbi-artifacts.s3.eu-central-1.amazonaws.com/a270f095-0c79-4775-a4c4-790178457031/result.html
I've untagged this package for now from f37 tag.
Thanks - sorry about that! :( I will continue to work with upstream to get the support for using system libffi working again with the newer GHC buildsystem.
In the meantime, let's filter the libffi.so.8()(64bit) provides out? https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/
Ah thanks Miro 👍 - that idea had crossed my mind too, but I didn't look into it. Anyway this was already fixed upstream now thankfully and I backported it to ghc9.4 already. Also I plan to backport it to ghc9.2 later, though that might be slightly harder perhaps - anyway it is on an older different libffi soname so it is less problematic.