Bug 733954 - Stop generating source RPM tags from BuildRequires
Summary: Stop generating source RPM tags from BuildRequires
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 733949
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-28 21:28 UTC by Matt McCutchen
Modified: 2011-10-24 16:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-17 08:01:02 UTC


Attachments (Terms of Use)

Description Matt McCutchen 2011-08-28 21:28:01 UTC
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)

Comment 1 Panu Matilainen 2011-10-17 08:01:02 UTC
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.

Comment 2 Matt McCutchen 2011-10-24 16:07:24 UTC
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?


Note You need to log in before you can comment on or make changes to this bug.