[Fedora-packaging] arched BuildRequires?

Toshio Kuratomi a.badger at gmail.com
Thu Jun 13 18:53:45 UTC 2013

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:


Thanks to mschwendt for explaining the rationale so clearly.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20130613/f1a2e7fc/attachment.sig>

More information about the packaging mailing list