Description of problem: Currently, the packages libfoo, libfoo-openmpi and libfoo-mpich providing the library libfoo.so all have a provides string of i.e. libfoo.so()(64bit) While yum used a shortest-package-name rule to choose which package to pick, dnf does not have any rules, and seems to just pick the first match it comes across. Currently the only solution would be to filter the provides from the -openmpi, -mpich packages and add explicit Requires: where needed. I'd like to propose to extend the provides string in such way that it also encodes the MPI implementation, i.e.: $ rpm -qp --provides libfoo libfoo.so()(64bit) $ rpm -qp --provides libfoo-mpich libfoo.so()(64bit)(mpich-x86_64) $ rpm -qp --provides libfoo-openmpi libfoo.so()(64bit)(openmpi-x86_64) To this end, I'm proposing to adapt the find-requires and find-provides scripts as (or similarly to): - https://smani.fedorapeople.org/find-provides - https://smani.fedorapeople.org/find-requires See also [1] for the discussion on fedora-devel leading to this change proposal. [1] https://lists.fedoraproject.org/pipermail/devel/2015-June/211318.html To coordinate the needed mass rebuild of MPI packages, I'm drafting a change at https://fedoraproject.org/wiki/User:Smani/RpmMPIReqProv
To clarify one thing: I initially thought of having these scripts included as mpi-find-requires and mpi-find-provides and have a %{?mpi_package_header} to override __find_requires and __find_provides, however I wonder whether it is not easier to just have it globally enabled, to remove the risk of inconsistencies between regular find-{requires,provides} and mpi-find-{requires,provides}. But I'm happy either way.
A nice explanation by T.C. Hollingsworth [1] explained how to implement this the right way, so I'm closing this bug and I'll proceed with the outlined strategy. [1] https://lists.fedoraproject.org/pipermail/devel/2015-June/211570.html