Since the last build of boost in rawhide its dependencies have been broken. Trying to install boost-openmpi-1.63.0-6.fc27.x86_64 results in this error: nothing provides libboost_mpi.so.1.63.0()(64bit) needed by boost-openmpi-1.63.0-6.fc27.x86_64. That dep is a library provided by that same package, so it's failing a dep that can only be provided by itself! Examining it shows the Provides has the MPI suffix, so doesn't match: $ rpm -qp --provides /var/lib/mock/fedora-rawhide-x86_64/result/boost-openmpi-1.63.0-6.fc27.x86_64.rpm boost-openmpi = 1.63.0-6.fc27 boost-openmpi(x86-64) = 1.63.0-6.fc27 libboost_mpi.so.1.63.0()(64bit)(openmpi-x86_64) ^^^^^^^^^^^^^^^^ In F25: $ dnf repoquery --requires boost-openmpi.x86_64 | grep libboost libboost_serialization.so.1.60.0()(64bit) In rawhide: $ dnf repoquery --requires boost-openmpi.x86_64 | grep libboost libboost_serialization.so.1.63.0()(64bit) libboost_mpi.so.1.63.0()(64bit) <==== this doesn't seem right So something is now broken in the rawhide autodeps, causing a package to depend on its own libraries, but without the MPI suffix used on the corresponding Provides. If it's intentional that a package depends on itself, rpm-mpi-hooks needs to be updated to include the suffix when a package Requires its own libraries.
Looking into it.
I'm not sure rpm-mpi-hooks is to blame here? Se full log with debug output below, but: while scanning for the requires of libboost_mpi.so.1.63.0, libboost_mpi.so.1.63.0 ends up listed as requires *of itself* despite mpi.req never emitting that requires (and neither elfdeps FWIW). Processing files: boost-openmpi-1.63.0-5.fc27.x86_64 Executing(%license): /bin/sh -e /var/tmp/rpm-tmp.nmfc0F + umask 022 + cd /builddir/build/BUILD + cd boost_1_63_0 + LICENSEDIR=/builddir/build/BUILDROOT/boost-1.63.0-5.fc27.x86_64/usr/share/licenses/boost-openmpi + export LICENSEDIR + /usr/bin/mkdir -p /builddir/build/BUILDROOT/boost-1.63.0-5.fc27.x86_64/usr/share/licenses/boost-openmpi + cp -pr LICENSE_1_0.txt /builddir/build/BUILDROOT/boost-1.63.0-5.fc27.x86_64/usr/share/licenses/boost-openmpi + exit 0 Getting requires for /builddir/build/BUILDROOT/boost-1.63.0-5.fc27.x86_64/usr/lib64/openmpi/lib/libboost_mpi.so.1.63.0... => Req: libgcc_s.so.1(GCC_3.0)(64bit) => Req: libc.so.6(GLIBC_2.4)(64bit) => Req: libc.so.6(GLIBC_2.14)(64bit) => Req: libc.so.6(GLIBC_2.2.5)(64bit) => Req: libstdc++.so.6(CXXABI_1.3.8)(64bit) => Req: libstdc++.so.6(GLIBCXX_3.4.9)(64bit) => Req: libstdc++.so.6(CXXABI_1.3.9)(64bit) => Req: libstdc++.so.6(CXXABI_1.3)(64bit) => Req: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) => Req: libstdc++.so.6(GLIBCXX_3.4)(64bit) => Req: libboost_serialization.so.1.63.0()(64bit) => Req: libmpi.so.20()(64bit)(openmpi-x86_64) => Req: libmpi_cxx.so.20()(64bit)(openmpi-x86_64) => Req: librt.so.1()(64bit) => Req: libstdc++.so.6()(64bit) => Req: libm.so.6()(64bit) => Req: libgcc_s.so.1()(64bit) => Req: libpthread.so.0()(64bit) => Req: libc.so.6()(64bit) => Req: rtld(GNU_HASH) --- Provides: boost-openmpi = 1.63.0-5.fc27 boost-openmpi(x86-64) = 1.63.0-5.fc27 libboost_mpi.so.1.63.0()(64bit)(openmpi-x86_64) Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: libboost_mpi.so.1.63.0()(64bit) libboost_serialization.so.1.63.0()(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libm.so.6()(64bit) libmpi.so.20()(64bit)(openmpi-x86_64) libmpi_cxx.so.20()(64bit)(openmpi-x86_64) libpthread.so.0()(64bit) librt.so.1()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(CXXABI_1.3.8)(64bit) libstdc++.so.6(CXXABI_1.3.9)(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit) libstdc++.so.6(GLIBCXX_3.4.21)(64bit) libstdc++.so.6(GLIBCXX_3.4.9)(64bit) rtld(GNU_HASH)
This should be fixed in rpm-mpi-hooks-5-1.fc27 that is building now. The %__mpilibsymlink_path was too open and was catching the build-id symlink that is now part of the package.
Great, thanks, Orion! Will a new boost build be needed?
yes, packages with the bad requires will need to be rebuilt with the new rpm-mpi-hooks.