[Fedora-packaging] arched BuildRequires?

[Panu Matilainen]

On 06/13/2013 09:53 PM, Toshio Kuratomi wrote:
> On Thu, Jun 13, 2013 at 08:30:19PM +0200, Michael Schwendt wrote:
>> On Thu, 13 Jun 2013 19:09:29 +0200, Mattias Ellert wrote:
>>
>>> If what you say above was true it would be a problem. But it doesn't
>>> work like that.
>>
>> True, it doesn't really work like that, but %_isa in BuildRequires
>> adds a confusing problem nevertheless.
>>
>> BuildRequires in the spec file become the src.rpm's Requires.
>> If those Requires are arch-specific, you cannot use tools like
>> yum-builddep or "rpm" to query the package's build requirements.
>> You would need to reconstruct the src.rpm always for the target
>> arch (not only if there are arch-conditional BuildRequires).
>>
>> The src.rpm is built on an arbitrary build host, and Fedora publishes
>> a single src.rpm build in the sources repo. It's just lame if the user
>> of an x86_64 installation downloads src.rpm packages, which contain
>> x86-32, ppc or other arch-specific dependencies. That doesn't add any
>> value at all.
>>
>>> $ rpmbuild --rebuild globus-common-14.9-3.fc18.src.rpm
>>
>> That doesn't evaluate the src.rpm's Requires as yum-builddep or "rpm -qpR" do.
>> So, why obfuscate the BuildRequires and the src.rpm's Requires?
>>
>>> ... build succeeds ... because the BRs needed on the build system's architecture are there
>>>
>>
>> Nasty, isn't it? The package specifies '(x86-32)' requirements, but you've
>> just built for '(x86-64)'.
>
> The FPC discussed this today and added a prohibition to using %{_isa} in
> BuildRequires to the Guidelines:
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_and_.25.7B_isa.7D
>
> Thanks to mschwendt for explaining the rationale so clearly.

"You MUST NOT use arched BuildRequires. The arch ends up in the built 
SRPM but SRPMs need to be architecture independent. "

By this logic you should also ban arch-conditional BuildRequires. And a 
whole bunch of other similar constructs. Which is not going to work 
because those constructs are actually needed.

What's broken is the assumption that SRPM is a truly arch-independent 
entity when its not, and the source repository layout which stems from 
the assumption.

The only reliable way to evaluate build-requires is by parsing the spec 
for the build target architecture, ie 'yum-builddep foo.spec'.

	- Panu -