Description of problem: When a source RPM is generated, the BuildRequires (analogously BuildConflicts, throughout) are expanded for the target architecture and attached as Requires and tags. But BuildRequires are in general architecture-specific, semantically at least. (They are often written without the architecture specificity, and one may be able to get away with this depending on the configured repositories, but that is poor practice.) It follows that the Requires of an SRPM are in general incorrect for target architectures other than the one under which the SRPM was generated, so tools such as mock use alternative methods to get the BuildRequires for the specified target architecture. Given that SRPM Requires are in the general sense useless and are the only source of substantive nonreproducibility in SRPMs, I propose that they be removed and replaced with rpmlib(NoSRPMBuildRequirements) or so to make old RPM building tools fail up front with a meaningful error. Ironically, this would break mock's current workaround of regenerating the SRPM for the specified target architecture, so it cannot become the default until mock switches to using yum-builddep on the spec file (bug 733949). Version-Release number of selected component (if applicable): rpm-4.9.1.1-1.fc15 How reproducible: Always Steps to Reproduce: 1. rpmbuild -bs ... 2. rpm -qp --requires .../SRPMS/*.src.rpm Actual results: BuildRequires expanded for the default target architecture Expected results: rpmlib(NoSRPMBuildRequirements)
NAK. More or less all the metadata carried by an SRPM is (at least subject to being) specific to the arch/platform where it was generated, always has been. That the data contained in SRPMS is not fit for some particular purpose (such as "source repository" metadata) only means it shouldn't be used for that purpose, it doesn't make the data useless. Removing the build-requires from SRPMS would accomplish precisely nothing except break legal usages such as what mock is currently doing. mock might indeed be better off with using yum-builddep on spec now that it's possible, but that's not a reason to break 15 years of backwards compatibility.
I can't argue with your conclusion, though I may make the change on my system since I have less of an interest in long-term backward compatibility. Some questions: > More or less all the metadata carried by an SRPM is (at least subject to > being) specific to the arch/platform where it was generated, always has been. Concretely, what other fields are architecture or platform dependent? > That the data contained in SRPMS is not fit for some particular purpose (such > as "source repository" metadata) only means it shouldn't be used for that > purpose, it doesn't make the data useless. Is it fit for some other purpose for which a better alternative is not already available? > Removing the build-requires from > SRPMS would accomplish precisely nothing except break legal usages such as what > mock is currently doing. What it would accomplish is to definitively break callers that make the incorrect assumption that the build requirements in the SRPM header are architecture independent and force them to adopt a different approach, hopefully a correct one. Is anything else in Fedora in the same situation as mock?