On Thu, 13 Jun 2013 19:09:29 +0200, Mattias Ellert wrote: > tor 2013-06-13 klockan 17:34 +0200 skrev Simone Caronni: > > > > > Exactly, here an example of a Koji build done with _isa'ed > > BuildRequires (taken from the link I've posted before): > > > > $ rpm -qpR libguac-client-vnc-0.6.0-4.fc17.src.rpm > > cairo-devel(x86-64) > > gnutls-devel(x86-64) > > libguac-devel(x86-64) = 0.6.0 > > libvncserver-devel(x86-64) > > rpmlib(FileDigests) <= 4.6.0-1 > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > > > This means I can't rebuild the src.rpm on an i686. This is wrong. > > 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)'. -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.4-301.fc19.x86_64 loadavg: 0.17 0.08 0.06 -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
