I've just ran into similar problem as described in bug 678000 (thus
this is to be its effective clone).  It was while making brew build
for RHEL 5.8, but the same is with the current Fedora and I don't think
anything has changed for RHEL 6 so I am targetting this bug/proposal
to be considered for RHEL 6.4 (and perhaps RHEL 5.9) or later.


Let's have a look what can be a successful application of a patch
when rpmbuild'ing for RHEL 6 (hopefully I covered all the possibilities):

  level of match    | ``patch -s --fuzz=0'' patch application (RHEL 6)
--------------------+-----------------------------------------------------
 A - fuzz=0 match   |
   - hunks start    | perfect application: everything OK, no side effects
     lines match    |
--------------------+-----------------------------------------------------
 B - fuzz=0 match   | successful application, everything seems OK, but
   - hunk start     | there is a side efect: creating <patched>.orig
     line w/ offset | without any indication (due to ``-s'' option)
--------------------+-----------------------------------------------------

AFAIK there is no other variant of successful patch application when
using mentioned flags to ``patch'' as enforced by rpmbuild internals
(I noticed ``%patch1'' in spec generally does not support all
the options ``patch'' does).

On RHEL 5 (5.8), ``--fuzz=0'' is not enforced meaning that default
fuzz boundary (2) is used instead so there would be another 0<fuzz<3
entry (regardless whether hunk start line matches exactly or not)
in the table, call this variant C, with the same description as B.

Apparently, ideal state is when the patch matches as in case A.
The case of B (C) will, due to partial mismatch, force creating that
backup file (with trailing ``.orig'' by default) while remaining silent
due to enforced ``-s''.  Undesirably, such unnoticed file can then find
its way to the final package (fortunately, rpmdiff can spot this);
just a too liberal ``make install'' in a patched 3rd package without
filtering out artificial objects and <patched>.orig is brought in.


Now the question is whether there would be a profit in restricting
patches into the well-fitting A-case only or not.  As ``patch'' itself
seems not to provide any mean for such spartan restriction, there would
have to be a wrapper around ``patch'' on the rpmbuild's side that would
fail either with ``patch'' failure or if the <patched>.orig file has been
generated (or change in ``patch'' upstream would be feasibe?).

If this is not the right way (B/C also OK), I would join original issuer
from bug 678000 in suggesting removal of ``-s'' option for ``patch''
invocations by rpmbuild.


Either would make the packaging a bit more pleasant and less error-prone.
In either case, one would get immediate feedback that something is wrong
when running ``rpmbuild -bp'' locally and when the overall build has
failed (case A) or at least from build.log stating that the patch hasn't
been applied cleanly (B+C cases).

Thanks for considering this!