Bug 441473

Summary: Check BuildRequires before warning of unknown tags
Product: [Fedora] Fedora Reporter: Ed Avis <ed>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: pnasrat
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-02 10:05:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ed Avis 2008-04-08 10:42:12 UTC
When running 'rpmbuild -ba some.spec', if the spec file contains a tag that rpm
doesn't know about, you get an error

error: line 1: Unknown tag: %whatever

These errors should be reported, and they should stop the spec file from
building, but it would be useful for rpm to continue reading the spec file and
report missing BuildRequires at least.

Why is this useful?  Sometimes third-party source packages have particular tags
that are defined in an 'rpm-config' package you need to install first.  But at
the moment there is no way to use BuildRequires to say that the config package
must be loaded.  Instead rpmbuild gives the unknown tag error first, stops
processing the file, and never gets as far as BuildRequires.

The more user-friendly output would be something like

error: line 1: Unknown tag: %whatever
error: Failed build dependencies:
    whatever-rpm-config is needed by some.fc8.noarch

Comment 1 Panu Matilainen 2008-10-02 10:05:15 UTC
I see your point, but consider the following, perfectly valid macro definition in whatever-rpm-config:

%whatever BuildRequires: whatever-rpm-config

At which point any attempt to continue parsing would be completely moot. This simply can't be done reliably at all, so there's not much point in even trying.