Bug 554854

Yes, that looks wrong to me, too. IMHO an architecture (the architecture the
source package has been built on) should never get listed as a requirement of
a *.src.rpm.

you know - it kinda feels like this should be expanded out from the spec file at build time of the pkg not build time of the srpm - but I know what that would involve. :(

src.rpm headers have always been architecture specific, nothing new here. Its just that using %{_isa} in BuildRequires just makes it more visible than before. 

There's nothing (well, except possible distro-specific packaging policies) stopping people from using something like (just an artificial example):
   BuildRequires: %{_libdir}/tclConfig.sh
..which would end up in src.rpm requires as /usr/lib/tclConfig.sh or /usr/lib64/
tclConfig.sh depending on which architecture the src.rpm happened to be created on. Or conditional buildrequires like
   %ifarch %{x86}
   BuildRequires: foo
   %endif

And sure, this conflicts with how people would like to (and do) distribute src.rpms.

Various options include
1) Have mock pass '--define "_isa %{nil}"' to rpmbuild when generating the src.rpm (cures the symptom in this bug but not the disease)
2) Ban arch-specific constructs in BuildRequires by packaging policy
3) Stop distributing src.rpms and point people to dist-cvs instead, this would put an end to the pretense that src.rpm's are arch-independent when they are not...

(In reply to comment #3)
> src.rpm headers have always been architecture specific, nothing new here. Its
> just that using %{_isa} in BuildRequires just makes it more visible than
> before. 
> 
> There's nothing (well, except possible distro-specific packaging policies)
> stopping people from using something like (just an artificial example):
>    BuildRequires: %{_libdir}/tclConfig.sh
> ..which would end up in src.rpm requires as /usr/lib/tclConfig.sh or
> /usr/lib64/
> tclConfig.sh depending on which architecture the src.rpm happened to be created
> on. Or conditional buildrequires like
>    %ifarch %{x86}
>    BuildRequires: foo
>    %endif

Yes, but all except the last are pointless unless they're evaluated at *build* time, not SRPM creation time.

Really, if you're adding %{_isa} to build requires, it's not that you actually care at all what the value of %{_isa} is; you just care it's the same for all the packages you're attaching it to. Hence, setting the value in the source rpm seems wrong.

Getting rid of %{_isa} in src.rpm might be possible by adding a separate spec parse round with %{_isa} defined to %{nil}, but there's no way to generically fix this: you dont care what the value of eg %{_libdir} is either until at build-time, but nevertheless its value at the time of src.rpm generation ends up in src.rpm dependencies and there's no correct arch-independent substitute for it. Requires of a src.rpm can be unresolvable on a different architecture than was used to generate the src.rpm and there's no helping it, except by packaging policy.

I'll remove the %{_isa} from BuildRequires of rpm.spec, there's not much else to be done about it.

Mm... ok there are over 50 packages using %{_isa} in buildrequires so removing from rpm.spec alone wont do any good.

Again, a possible workaround for the %{_isa} case is to have mock generate the src.rpm with --define "_isa %{nil}" but there's no generic way to eliminate arch-dependent pieces ending up in src.rpms. Of course this way its possible to have build-requires depsolve succeed but actual build still fail due to missing buildrequires. Which is probably better than not being able to depsolve them at all, but somewhat ugly.

Jesse - would it be possible to set that in the mock config?

It should be possible, but it would take patching koji too I think, since koji writes out the mock config files.

Panu, can you come up with any scenario where isa in BuildRequires is actually useful?  I'm having a hard time coming up with one.  Unlike the other macros in srpms that are arch dependent, most of those don't wind up in BuildRequires, which is the one thing we really care about in srpms (and spec files).

For a mock build, isa is probably not useful. But for people who still use just rpmbuild, and multilib, it's easy to get screwed without isa in BuildRequires (or at least it'd seem that you'd want it, if you didn't check what actually happened).

Yup, the main case for isa in BuildRequires is getting sensible behavior when doing rpmbuild for a secondary arch, eg:
[pmatilai@dhcp102 SPECS]$ uname -m
x86_64
[pmatilai@dhcp102 SPECS]$ rpmbuild -bb --target i686 rpm.spec
Building target platforms: i686
Building for target i686
error: Failed build dependencies:
	db4-devel(x86-32) is needed by rpm-4.8.0-2.fc12.i686
	elfutils-devel(x86-32) >= 0.112 is needed by rpm-4.8.0-2.fc12.i686
	elfutils-libelf-devel(x86-32) is needed by rpm-4.8.0-2.fc12.i686
	readline-devel(x86-32) is needed by rpm-4.8.0-2.fc12.i686
        ...

Without isa, you'd get varying errors in the middle of the build despite rpm seeming happy about buildrequires.

Of course whether %{_isa} is in src.rpm or not, this doesn't work with something like yum-builddep - as has been noted here the only meaningful place to figure buildrequires is at build, not src.rpm generation time. I wasn't joking about dropping distribution of source rpms and pointing people to dist-cvs instead.

Oh and adding an API to rpm-python for resolving build-requires from a spec wouldn't be hard at all, it's just not there yet.

dist-cvs/dist-git is a non-starter; attempting to distribute source that way fails various GPL provisions.

> Of course whether %{_isa} is in src.rpm or not, this doesn't work with
> something like yum-builddep

 Well if you "fix" rpmbuild, then I'm pretty sure we can change yum-builddep to work too.

This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

this has not been "fixed" yet.  Retagging with rawhide.

IMO, putting arch-specific build requirements on the SRPM is broken design.  And starting in F15, yum-builddep works on spec files (bug 379181).  So I propose to have mock run yum-builddep on the spec file (bug 733949) and then remove the build requirements from SRPMs entirely (bug 733954).

If the RPM team supports the above, I suggest duping this bug to bug 733954.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Any news? Last package in repository with isa deps.

Fixed in rawhide (rpm-4.11.2-10.fc21).