Description of problem: If external scripts are used to compute provides and/or requires, the exit codes of these scripts are not checked. Version-Release number of selected component (if applicable): 4.4.2-37.el5 but I believe is is still in devel. How reproducible: 100% Steps to Reproduce: 1. rpmbuild -bb elephant.spec (Use the attached spec file.) Actual results: Happily writes an errorneous binary rpm. Expected results: The build should not create any binary rpm. Additional info: The exit conde of find-requires is silently ignored. If find-provides fails, there is an error message, but this is still insufficient.
Created attachment 147102 [details] reproducer -- a spec file
Um, no. Here's your spec file run under rpm-4.4.8 (note /bin/sh -e invocation and the error message): ... Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.24672 + umask 022 + cd /usr/src/rpm/BUILD + rm -rf /var/tmp/elephant-root + rm -rf /var/tmp/elephant-root + mkdir /var/tmp/elephant-root + touch /var/tmp/elephant-root/elephant + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip + /usr/lib/rpm/brp-strip-static-archive + /usr/lib/rpm/brp-strip-comment-note + /usr/lib/rpm/brp-nobuildrootpath Processing files: elephant-1.0-1 D: execv(/bin/sh) pid 23028 D: waitpid(23028) rc 23028 status 100 error: /bin/sh failed Finding Provides: /bin/sh -c 'cat >/dev/null ; echo this; exit 1' error: Failed to find Provides: ... I'm pretty sure that rpm-4.4.2 behaves the same. Wanna bet? UPSTREAM or NOTABUG, at your pleasure.
What exactly are you expecting rpmbuild to do? The term "insufficient" is not exactly specific.
Index: files.c =============================================================== ==== RCS file: /cvs/devel/rpm/build/files.c,v retrieving revision 1.240.2.26 diff -u -b -B -w -p -r1.240.2.26 files.c --- files.c 21 Jan 2007 17:16:22 -0000 1.240.2.26 +++ files.c 1 Feb 2007 21:07:02 -0000 @@ -2650,7 +2650,8 @@ int processBinaryFiles(Spec spec, int in if ((rc = processScriptFiles(spec, pkg))) res = rc; - (void) rpmfcGenerateDepends(spec, pkg); + if ((rc = rpmfcGenerateDepends(spec, pkg))) + res = rc; /* XXX this should be earlier for deps to be entirely sorted. */ providePackageNVR(pkg->header);
# rpmbuild -ba elephant.spec Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.97465 + umask 022 + cd /usr/src/rpm/BUILD + rm -rf /var/tmp/elephant-root + rm -rf /var/tmp/elephant-root + mkdir /var/tmp/elephant-root + touch /var/tmp/elephant-root/elephant + /usr/lib/rpm/brp-compress + /usr/lib/rpm/brp-strip + /usr/lib/rpm/brp-strip-static-archive + /usr/lib/rpm/brp-strip-comment-note + /usr/lib/rpm/brp-nobuildrootpath Processing files: elephant-1.0-1 error: /bin/sh failed Finding Provides: /bin/sh -c 'cat >/dev/null ; echo this; exit 1' error: Failed to find Provides: Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 RPM build errors: /bin/sh failed Failed to find Provides:
UPSTREAM
Upstream at rpm.org now too (or will be once the system hosting the repo comes back alive, duh)
(In reply to comment #3) > What exactly are you expecting rpmbuild to do? The term "insufficient" is not exactly specific. If either find-provides or find-requires exist with a non-zero exit code, then: 1) no rpm file may be written to the disk 2) the exit code of rpmbuild must be non-zero
(In reply to comment #7) > Upstream at rpm.org now too (or will be once the system hosting the repo comes > back alive, duh) Please do not close as UPSTREAM, unless a reference to upstream bug report is provided. Secondly, as this is a severe bug, we should keep tracking it in Red Hat bugzilla until a fix lands into Fedora.
Severe? No it's not... severe in rpm land is when installations fail, rpmdb's get corrupted and so on. This is "just a bug" and one that very few people are ever going to hit and even then it does give you an error message instead of just silently failing. In this case, this bug equals upstream bug report and I already said it's fixed upstream at rpm.org so there are no reference to put in :) It'll be in the next major version, and also in 4.4.2.2 which will be released in a couple of months at this rate of fixes going in, it'll get to Fedora soon enough for. In the meanwhile, I'd rather close bugs that have been dealt with already, there are plenty enough hanging around as is.