Description of problem:
RPM macro %patchX should provide an option, which corresponds with "--no-backup-if-mismatch" option in "patch" utility.
Do not back up a file if the patch does not match the file exactly and if backups are not otherwise requested. This is the default if patch is conforming to POSIX.
Why we need this:
We have a directory with many tests in mysql package, while the whole directory is basically copied in %install section. When some of the tests are patched, while the patch doesn't apply smoothly (a message about "Hunk #x succeeded at offset ..." is printed) a backup file is still created even if we don't pass "-b" option to %patchX macro. And since we install the whole directory, this results in installing backup files (with standard suffix ".orig"). If we can pass "--no-backup-if-mismatch" to %patchX macro, this wouldn't happen.
Version-Release number of selected component (if applicable):
Actually, I think %patch should just include that option by default. It is not apparent to me that there's any use-case for having backup files made during an RPM build, and if anyone does want it, they can add -b to the %patch command.
For the packages where it matters you can achieve that already by adding this to the spec:
%global _default_patch_flags --no-backup-if-mismatch
As for globally enabling... I'll mull over it for a bit, everybody seems to want their patches slightly differently applied. Which is sort of why _default_patch_flags exists.
(In reply to comment #2)
> For the packages where it matters you can achieve that already by adding
> this to the spec:
> %global _default_patch_flags --no-backup-if-mismatch
Hm, that might be a sufficient solution. The cases where it matters, I think, are where the specfile blindly installs *everything* that's in a given source directory. I'm not sure whether that's common enough to justify changing the default.
I'd still vote for enabling --no-backup-if-mismatch by default. It can influence in a wrong way only such packages, that depend on patches applied uncleanly and still want to create backup with no -b specified, which is really broken design (that I hope is not used by anyone).
I'd vote for it too. I think the expectation of most packagers (certainly mine) is that if I don't use "-b" I don't get a backup file. See thread starting at https://lists.fedoraproject.org/pipermail/devel/2014-April/197506.html
An alternative would be to carry it in redhat-rpm-macros
There is a thing called "Open Build Service" which is used to automatically build packages for openSUSE, Fedora and a bunch of other distroes. It considers existence of this "backup" cruft as fatal error of the build. I, as others, just can't even imagine why would you want them on package builds at all. Insane things like that is why I, personally, dream about times when rpm authors would bother to learn something from portage/ebuilds.
I added --no-backup-if-mismatch to _default_patch_flags in /usr/lib/macros in rawhide (rpm-4.13.0-0.rc1.32.fc25). We will see if there will be any objections.
Well, it did break some builds (ltrace, for one) but they deserve to be broken.
Would be nice to test things like this before pushing them, but I can understand that doing fedpkg prep on all of Fedora takes a while even if you start from the current git checkout seed.