|Summary:||RFE: enable --no-backup-if-mismatch by default in %patch macro|
|Product:||[Fedora] Fedora||Reporter:||Honza Horak <hhorak>|
|Component:||rpm||Assignee:||Packaging Maintenance Team <packaging-team-maint>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||ffesti, hhorak, jpokorny, jzeleny, lkardos, marcosfrm, orion, packaging-team, pahan, pmatilai, ppisar, redhat, rvokal, virtuousfox|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2016-04-15 11:12:23 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Honza Horak 2012-12-06 16:36:15 UTC
Description of problem: RPM macro %patchX should provide an option, which corresponds with "--no-backup-if-mismatch" option in "patch" utility. From patch(1): --no-backup-if-mismatch 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): rpm-4.10.1-3.fc18.x86_64
Comment 1 Tom Lane 2012-12-06 16:47:08 UTC
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.
Comment 2 Panu Matilainen 2012-12-07 08:19:28 UTC
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.
Comment 3 Tom Lane 2012-12-07 17:11:03 UTC
(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.
Comment 4 Honza Horak 2012-12-13 10:01:30 UTC
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).
Comment 5 Orion Poplawski 2014-04-05 15:20:32 UTC
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
Comment 6 Sergey Kondakov 2015-10-30 18:04:28 UTC
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.
Comment 7 Ľuboš Kardoš 2016-04-15 11:12:23 UTC
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.
Comment 8 Jason Tibbitts 2016-06-10 22:22:08 UTC
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.