Description of problem: I'm unable to install build dependencies of FreeIPA with dnf builddep any more. The command fails because it cannot find a matching package for /usr/lib/krb5/plugins/kdb/db2.so on X86_64. The path is wrong and should be /usr/lib64, not /usr/lib. Both FreeIPA and KRB5 spec files use %{_libdir}. The builddep command used to work a couple of weeks ago. I suspect an infrastructure and tooling bug, perhaps in rpm or dnf? Version-Release number of selected component (if applicable): rpm-4.14.2.1-2.fc29.x86_64 dnf-4.2.5-3.fc29.noarch krb5-server-1.16.1-25.fc29.x86_64 freeipa-server-4.7.3-2.fc29.x86_64 How reproducible: always, on F29 and F30 Steps to Reproduce: 1. dnf builddep freeipa-server Actual results: No matching package to install: '/usr/lib/krb5/plugins/kdb/db2.so' Not all dependencies satisfied Error: Some packages could not be found. Expected results: command should work Additional info: $ uname -p x86_64 $ rpm -qf /usr/lib64/krb5/plugins/kdb/db2.so krb5-server-1.16.1-25.fc29.x86_64 spec files from dist git, F29 branch: $ grep db2.so krb5.spec %{_libdir}/krb5/plugins/kdb/db2.so $ grep db2.so freeipa.spec BuildRequires: %{_libdir}/krb5/plugins/kdb/db2.so
There's only one src.rpm to represent all architectures, and whose src.rpm ends up in the repository is random. Because %{_libdir} depends on whether a 32bit or 64bit architecture was used to build that partcular src.rpm, it's only legit on systems with equal wordlength. Use of %{_lib} and %{_libdir} in buildrequires presents exactly the same problems as %{_isa}, and should be forbidden under the rationale (but to my surprise, is not in the current guidelines): https://docs.fedoraproject.org/en-US/packaging-guidelines/#_buildrequires_and_isa Of course, that all is just wiping the dirt under the carpet, it doesn't deal with the equally real problem of otherwise conditionalized build dependencies. One would think that dnf should at least warn if the src.rpm from the repository comes from a difference architecture, but it *cannot* because of a design flaw in the repository metadata, it cannot: the metadata doesn't store the actual architecture of src.rpm's but lies it to be "src" (to be treated similarly to "noarch"). So dnf in order to detect the arch difference, dnf would need to download the src.rpm header. All in all it's a pretty sad story. Anyway, the short-term fix is to eliminate the use of %{_libdir} in the freeipa-buildrequires.
Upstream ticket: https://pagure.io/freeipa/issue/8056
Panu, thank you very much for the detailed explanation. I'm going to remove %{_libdir} from our BuildRequires. This is the easiest fix for us.
Ack. It's sad that these constructs cannot be used in Fedora, as from rpm's POV there's absolutely nothing wrong with either %{_libdir} or %{_isa} in buildrequires, on the contrary they permit correctly expressing the dependencies for a multilib build. But it is what it is...
Fixed upstream master: https://pagure.io/freeipa/c/51836c0594d9f97ace8392c03d47aae883b87724
Fixed upstream ipa-4-8: https://pagure.io/freeipa/c/5de091bdd5fbe669d65411f97e3450bc87437f65
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
FEDORA-2019-75a963e4cb has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-75a963e4cb
freeipa-4.8.2-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-75a963e4cb
freeipa-4.8.2-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.