Bug 483385 - rpmbuild no longer fails when a patch fails to apply
rpmbuild no longer fails when a patch fails to apply
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
All Linux
urgent Severity medium
: ---
: ---
Assigned To: Roman Rakus
Fedora Extras Quality Assurance
: 485584 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-01-31 06:58 EST by drago01
Modified: 2014-01-12 19:08 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-06 06:07:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Revert to former behavior (648 bytes, patch)
2009-01-31 13:20 EST, Panu Matilainen
no flags Details | Diff

  None (edit)
Description drago01 2009-01-31 06:58:15 EST
In rawhide rpmbuild does not fail (abort the build) when a patch does not apply.

I consider this change as a bug because this way maintainers might not notice that a patch needs rebasing and ship a broken package.

In my case I upgraded beagle to 0.3.9 in rawhide (a patch did not apply), I only noticed that when backporting the release to F10 where rpm behaves as expected. (i.e patch does not apply -> build fails).

Please revert this change, before it causes more confusion and surprises.
Comment 1 Panu Matilainen 2009-01-31 10:22:27 EST
Easily reproduced locally in mock rawhide root, dropping bash down to 3.2 from F10 restores normal behavior, ie error out.

This is not caused by rpm change, this is either an intentional change of behavior or bug in bash 4.0. CC'ing bash maintainer for comments.
Comment 2 Panu Matilainen 2009-01-31 10:51:48 EST
Ok here's a minimal reproducer, surely this is not intentional:
echo foo|cat /nosuchfile
echo "here: $?"

With bash 3.2.39 from F10:
[pmatilai@turre ~]$ sh -e /var/lib/mock/fedora-rawhide-x86_64/root/tmp/bashtst.sh 
cat: /nosuchfile: No such file or directory
[pmatilai@turre ~]$

With bash 4.0.0(1)-rc1 from rawhide:
mock-chroot> sh -e /tmp/bashtst.sh 
cat: /nosuchfile: No such file or directory
here: 1

It's the pipe that throws bash off somehow, despite getting error code right. Removing "echo foo|" makes bash 4 error out at the failing 'cat'.
Comment 3 Panu Matilainen 2009-01-31 13:20:14 EST
Created attachment 330527 [details]
Revert to former behavior

From execute_cmd.c:

      /* 10/6/2008 -- added test for pipe_in and pipe_out because they indicate
         the presence of a pipeline, and (until Posix changes things), a
         pipeline failure should not cause the parent shell to exit on an
         unsuccessful return status, even in the presence of errexit.. */

Attached patch "fixes" this by removing the new pipe-checks, correct it probably is not :) I dunno what POSIX says about this but it's not the pipe itself that's failing here, the last command of the pipeline is.
Comment 4 Roman Rakus 2009-02-10 08:21:01 EST
Panu hits the nail on the...
If there will be check like (exit_immediately_on_error && pipe_in == NO_PIPE && pipe_out == NO_PIPE && exec_result != EXECUTION_SUCCESS), then bash -e will never exit immediately if a command (in this case pipeline) exits with a non-zero status.
Bug reported upstream: 
Comment 5 Roman Rakus 2009-02-10 12:02:11 EST
The Posix says:
    When this option is on, if a simple command fails for any of the reasons
listed in Consequences of Shell Errors or returns an exit status value >0, and
is not part of the compound list following a while, until, or if keyword, and
is not a part of an AND or OR list, and is not a pipeline preceded by the !
reserved word, then the shell shall immediately exit.

For me this looks like that Posix is not clear as it should be. They are
talking about simple commands, but later the words `s not a pipeline preceded
by the ! reserved word' makes no sense, if they are talking only about simple
Comment 6 Ulrich Drepper 2009-02-10 12:29:47 EST
I have already brought this up with the Austin Group.


One follow-up is


I think the consensus is that the new bash behavior is wrong.  Chat used POSIX compliance as the argument to change it.  This will hopefully mean he'll change it back before 4.0 final.

For the RH bash 4.0.rc1 package, the maintainer can and should already release a new version of the RPM with this change reversed.
Comment 7 Roman Rakus 2009-02-11 07:23:06 EST
Fixed in bash-4.0-0.4.rc1.fc11
Comment 8 Jindrich Novy 2009-02-15 06:56:03 EST
*** Bug 485584 has been marked as a duplicate of this bug. ***
Comment 9 Roman Rakus 2009-05-06 06:07:24 EDT
No other problems -> closing.

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