Description of problem: The Fedora buildsystem does this to parse a .spec file and extract info on name, version, release: rpm -q --qf "%{VERSION} %{RELEASE}\n" --specfile foo.spec | head -1 This works with %REQUIRES as well by not %BUILDREQUIRES. I'd like to parse specfiles to determine the build requirements and populate a build filesystem with the deps using yum. It would be great if also %BUILDREQUIRES could be parsed from the specfile in the same manner, is this hard to achieve? Can you point me to some place in the code where I could (presumably) hack in a few lines to support this? BTW: I'm assuming the RH Bugzilla is the "official" bugzilla for rpm.org, if that's not the case, pls point me to the proper place to file bugs like this.
Tried using yum-builddep?
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
Yeah, yum-builddep doesn't take a spec file, there's a chicken and the egg problems with developing packages and automation. The first time you build a new package one needs to manually install build dependencies then have a valid spec file and sources in order to generate the first valid source rpm. It would be nice to automate the "manually install build dependencies" by just providing one command `yum-builddep --specfile foo.spec' instead of parsing that out with greps and stuff.
and grep does not work because ... ? [herrold@centos-5 zoneminder]$ rpm -q --qf "%{VERSION} %{RELEASE}\n" --specfile perl-X10.spec 0.03 11orc 0.03 11orc [herrold@centos-5 zoneminder]$ grep -i ^buildrequire perl-X10.spec BuildRequires: perl(Astro::SunTime) BuildRequires: perl(Device::SerialPort) BuildRequires: perl-Time-modules [herrold@centos-5 zoneminder]$
It could be that easy, but it might be something like BuildRequires: perl(Astro::SunTime) (>= 1.2.3), perl(Device::SerialPort), zsh (== 2.3.4) BuildRequires: perl-Time-modules BuildRequires: jpeg-devel So now I have to do version checking to make sure zsh is available at version 2.3.4 and the perl(Astro::SunTime) is available greater than 1.2.3. grep can't handle that so well.
yeah -- spec files still (and forever will, due to installed base) lack a grammar, and people stuff false build requires into them as well. There are a number of hacked together systems to emit nominally well formed spec files out there So you know, %{arch} conditionals and more will play havoc, and some macro sets look at the target build environment and add even more 'oddball' corner cases reality is messy like that Fortunately sucking offenders into a VCS, and bumping a release version. and mungeing to taste for local build systems is really, at the end of the day, dead simple ... one assumes a end goal, such as an auto-seeking builder, satisfying all documented dependencies, is sought I'd like a pink pony and the Holy Grail as well ;) best regards
A pink pony and the Holy Grail don't type on a keyboard so well. But it would be useful to pull build dependencies out of a spec file correctly somehow. rpmbuild -q --qf '%{BUILDREQUIRES}' --target i686 --define ' foo bar' foo.spec rpmbuild --showrc --target i686 --define ' foo bar' foo.spec | grep -i buildrequires yum-builddep --specfile foo.spec rpm -q --qf '%{BUILDREQUIRES}' --macrofile foo.spec rpm --showrc foo.spec | grep -i buildrequires
I dont see ancient artifacts or ponies of any color here, just a perfectly reasonable RFE that's been a long time coming. This is implemented now upstream on several fronts: the C and Python API's now support querying the srpm header too, and there's also a new 'rpmspec' commandline tool for the purpose. For example: [pmatilai@dhcp102 SPECS]$ rpmspec -q --buildrequires dummy.spec python >= 2.7 libfoo(x86-64) > 1.2 bar-general [pmatilai@dhcp102 SPECS]$ rpmspec -q --target i686 --buildrequires dummy.spec python >= 2.7 libfoo(x86-32) > 1.2 bar-i686-optimized At least parts of this could be backported to rpm 4.8.x too, leaving open for now for tracking status in Fedora.
Fixed in rawhide as of rpm-4.9.0-0.beta1.1.fc15 (see comment #8)
I compiled latest rpm source(v4.11.90) from here git clone git://rpm.org/rpm.git and --build-requires is not a valid parameter ./rpmspec --version RPM version 4.11.90 ./rpmspec --help Usage: rpmspec-rh6-x86_64 [OPTION...] Spec options: -P, --parse parse spec file(s) to stdout -q, --query query spec file(s) --rpms operate on binary rpms generated by spec (default) --srpm operate on source rpm generated by spec --target=STRING override target platform --queryformat=QUERYFORMAT use the following query format Common options for all rpm modes and executables: -D, --define='MACRO EXPR' define MACRO with value EXPR --undefine=MACRO undefine MACRO -E, --eval='EXPR' print macro expansion of EXPR --macros=<FILE:...> read <FILE:...> instead of default file(s) --nodigest don't verify package digest(s) --nosignature don't verify package signature(s) --rcfile=<FILE:...> read <FILE:...> instead of default file(s) -r, --root=ROOT use ROOT as top level directory (default: "/") --dbpath=DIRECTORY use database in DIRECTORY --querytags display known query tags --showrc display final rpmrc and macro configuration --quiet provide less detailed output -v, --verbose provide more detailed output --version print the version of rpm being used Options implemented via popt alias/exec: Help options: -?, --help Show this help message --usage Display brief usage message I also don't see BUILDREQUIRES and a query tag. My Fedora 19 machine has the parameter though and it's only 4.11.1. One would gather this fix didn't make it upstream, however git commit history shows Panu Matilainen has made many commits to repo.
Douglas, better to report it to upstream I guess: latest version in Fedora rawhide is also 4.11.1. http://www.rpm.org/wiki/Communicate
Douglas, look again, correct usage is $ rpmspec -q --buildrequires my.spec which should be just a convenient alias to $ rpmspec -q --srpm --requires my.spec Both worked for me with rpmspec from rpm-build-4.11.1-7.fc20.x86_64 package.