Hide Forgot
description of problem: The following query always produces '(none)' as outout, given a valid specfile: rpm -q --qf='[%{SOURCE}\n]' --specfile filename.spec I would expect it to print the Source files named in the specfile, the same as rpm -q --qf='[%{SOURCE}\n]' -p filename.src.rpm does. The same applies to the Patch tag. I'd like to use this feature to help automate our Subversion integration and package building, so that I can ensure sources are present and up-to-date, but at present it's not possible without parsing specfiles by hand. Version-Release number of selected component (if applicable): $ rpm --version RPM version 4.3.3 How reproducible: See below. Steps to Reproduce: 1. take valid specfile with some Source tags 2. rpm -q --qf='[%{SOURCE}\n]' --specfile filename.spec 3. Actual results: text '(none)' is printed. Expected results: Value of all Source tags from specfile should be printed. Additional info: Also fix for Patch0..n, please
Try creating a srpm before querying, not hard. There are a large number of difficulties with the --specfile querying that are not easily solved.
Thanks, but ... build an SRPM to see if the sources are up to date so that I can then build an SRPM ? I'm not sure that always hangs together. It depends on the sources at least being all present in the first place. I think it's probably easier not to reply on rpm for querying specfiles. But I'll have a quick look at the source and see if I can understand why these two tags are so hard to implement usefully. Nick
The fundamental problem is that RPMTAG_SOURCE (and RPMTAG_PATCH) are added just before packaging a source rpm, not during parsing of a spec file. So --specfile which parses the specfile, and then queries the tags within binary headers, cannot query info that doesn't exist. Note binary, not source, rpm header(s) used for querying as well.
Fixed in rpm cvs, should be in rpm-4.4.9-0.2 when built. UPSTREAM
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.