On Thu, 13 Jun 2013 22:44:53 +0200, Mattias Ellert wrote:
tor 2013-06-13 klockan 19:20 +0200 skrev Björn Esser:
What will break the spec by removing _isa-macro from BRs? Is there any PROVEN reason for this? I'm NOT talking about the final-Requires in spec.
It is VERY EASY to construct such an example.
Sure, that's the known corner-case for multiarch installations.
It's similar for any arch-conditional build requirements in spec files. They are a bit of a hindrance, since one cannot rely on a downloaded src.rpm's Requires being complete. Unless one rebuilds the src.rpm first and then proceeds with the changed list of possibly arch-specific Requires in the freshly built src.rpm (e.g. as Mock does it before fetching the build requirements). Only then one can query the src.rpm with tools to install a long list of needed builddeps.
Consider a package containing the following BRs:
BuildRequires: nss-devel >= 3.10 BuildRequires: openssl-devel BuildRequires: cppunit-devel BuildRequires: glibmm24-devel BuildRequires: libdb-cxx-devel
All the BRs are satisfied:
$ rpm -q --whatprovides nss-devel openssl-devel cppunit-devel glibmm24-devel libdb-cxx-devel nss-devel-3.14.3-2.fc18.i686 openssl-devel-1.0.1e-4.fc18.x86_64 cppunit-devel-1.12.1-8.fc18.x86_64 glibmm24-devel-2.34.1-1.fc18.x86_64 libdb-cxx-devel-5.3.21-3.fc18.i686
Except for the minimum build environment, such as glibc-devel.i686 and libstdc++-devel.i686, the compiler(s) and preprocessor(s). The build would fail later on. %_isa in BRs here is like band-aid for a more fundamental problem, and it adds even another problem.
Oh, btw, not even all -devel dependencies use %_isa yet. On a normal x86_64 installation, installing something -devel.i686 often pulls in x86_64 deps. For your example, nss-devel.i686 will do that, too. %_isa would be needed in many many more places for multiarch operation.
rpmbuild correctly detects the missing BRs:
error: Failed build dependencies: nss-devel(x86-64) >= 3.10 is needed by canl-c++-1.0.0-2.fc18.x86_64 libdb-cxx-devel(x86-64) is needed by canl-c++-1.0.0-2.fc18.x86_64
Don't we prefer clean build environments, such as constructed by Mock? I know some people use "setarch i686 rpmbuild ..." and "setarch i686 yum ...", which accesses the full i386 repos on x86_64 installations.
Conclusively, I understand what you like about %_isa in BR, but I think it doesn't improve much compared with the confusion it adds.