[Fedora-packaging] arched BuildRequires?

[Panu Matilainen]

On 06/14/2013 01:42 PM, Panu Matilainen wrote:
> 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.

Actually its not even the source repository layout which is broken (it'd 
be insane to duplicate all the source for every arch just because 
src.rpm headers differ between arches), its the assumption that the 
metadata from such a repository can meaningfully be used for evaluating 
build-requires that is broken.

While we're at this (again): there are no guarantees that even the 
payload of an src.rpm is arch-independent, its trivial to create 
constructs where included sources and patches differ depending on what 
architecture an src.rpm was built. If people are worrying about src.rpm 
arch independence, THAT is what should be banned in the guidelines.

	- Panu -