Open zazaho opened 3 months ago
That's indeed the very same issue: the host tooling is wherever, but noarch %_libdir is always /usr/lib.
We'll need to better document this change.
In the meanwhile, packages will have to adapt. The current behavior is the right one from package's POV, ie a noarch package must be buildable with '--target noarch', and anything else is basically a packaging bug somewhere. Only, rpm doesn't offer very good tools for dealing with this.
In Fedora this very case is worked around with:
%global _qt5_qmake %{_bindir}/qmake-qt5
thank you for your insightful reply and the hint for how to fix
When build a noarch package (qt5-qttranslations) that uses
%{_qt5_qmake)
, the build fails because the path the_qt5_prefix
is resolved as/usr/lib/qt5
instead of the (host) valid path/usr/lib64/qt5
.I think this may be related to this issue: https://github.com/rpm-software-management/rpm/issues/2624
_qt5_prefix is defined in a macro as
%_qt5_prefix %{_libdir}/qt5
I have started to observe this behaviour since version 4.19.91